新刊ピックアップ

Webサービスをリリースしたあとに起きること

この記事を読むのに必要な時間:およそ 2 分

昨今,Webサービスは社会的なインフラになっています。Webだけで完結しない業態であっても,Web上で検索ができたり,販売や予約,申し込みができたりするものは多数あります。そのようなWeb上でのサービスを事業者が提供するためにはSaaSを使うこともありますが,より凝ったサービスを提供するため,あえて自前でWebサービスを実装することもあるでしょう。

一定以上の技術があるITエンジニアにとっては,なんらかのWebサービスを自分で実装して,インターネット上で提供することは容易な時代です。各種クラウドサービスを利用すれば,自前で回線やハードウェアを用意する必要もありません。開発してすぐに世界中からアクセスできる形で公開できます。

しかし,そのようにしてリリースされたWebサービスに人気が出て,アクセスが当初の予想よりも急増したらどうなるでしょうか。特に性能に気を配らずに素朴に実装されたWebサービスでは,同時に多数のアクセスが発生した場合に性能上の問題が発生することはよくあります。アクセスが増えるとレスポンスを返すまでに多くの時間が掛かったり,サーバーの負荷が高すぎてWebサービス自体が提供できなくなってしまったりすることは,残念ながら現代においてもしばしば発生しています。

内部の事情を把握できない利用者からは,⁠クラウドを使っているのだから,サーバーを増強すれば性能問題は解決するのでは?」と言われてしまうことがあります。しかし,(これを読まれているエンジニアの皆様ならよくご存じの通り)単純にお金を掛けてサーバーリソースを増強しさえすれば,そのまま素直に性能が上がっていくようなWebサービスは多くありません。

Webサービスを高速化する方法

性能に問題が発生しているWebサービスを高速化するためにはどうすればいいでしょうか。筆者の考えでは,どのようなWebサービスにも一撃で効くような銀の弾丸はありません。銀の弾丸はありませんが,性能を改善するための手法はあります。

Webサービスは,とても多くの要素で構成されています。Webアプリケーションを実装しているプログラミング言語,フレームワーク,データストアとして利用しているデータベースやキャッシュのためのミドルウェア,TCP/IPなどのネットワークスタック,それを動作するためのOS,物理的なハードウェア……図1⁠。

図1 Webサービスのコンポーネント

図1

実際に性能問題が発生している場合,大抵はこれら多くの構成要素のうちの,どこかにボトルネックが存在しています。ボトルネックとは,Webサービスを構成する一連の処理の流れの中で一番処理能力が低く,全体の処理能力の制約となってしまう箇所です。ボトルネックが性能の上限を決めている場合,それ以外の箇所にいくらお金を掛けて増強しても,全体の性能は改善しません。まず,この原理を理解しましょう図2⁠。

図2 ボトルネック

図2

ボトルネックになっている要素以外を増強しても意味がないということは,裏を返せば「ボトルネックを見つけて改善すれば効く」ということです。Webサービスを構成する要素に対して様々な方法でモニタリングを行い,問題の箇所を特定します。

ここでいうモニタリングとは,OSレベルでCPUやI/Oの負荷を観察するだけではありません。WebサーバーのアクセスログからURL別の処理時間を集計してアプリケーション上の問題を把握したり,データベース上で処理に時間が掛かっているSQLクエリを特定したりすることも含みます。

そうして実際のボトルネックが特定できれば,多くの場合,性能問題は解決したようなものです。問題になっている処理を高速化することが一番よい解決方法ですが,仮にそれができない場合でも,アプリケーションの仕様を見直せば問題が起きないようにできるかもしれません。特定箇所のリソースが不足していることが判明すれば,無闇にサーバー全体を増強するよりも効果的にコストを投入できます。

性能問題に対応するには

Webサービスの性能問題は,突然訪れます。待ち行列理論が明らかにするように,サービスの平均待ち時間は利用者が少ないうちはあまり変わりませんが,利用者が多くなると急激に悪化するためです。

立ち上げ時に実装してリリースしてから平時の運用をこなせているエンジニアでも,利用者が急増して性能が突然悪化した場合に適切な行動を取れるかどうかは分かりません。平時には経験しづらい事象にいざというときに対応するためには,どうすればいいでしょうか。

LINE社が主催しているWebサービスのパフォーマンスチューニングコンテストISUCONという競技があります。このコンテストでは,参加者にWebサービスが動作しているサーバーが与えられます。そこへサーバー外部から利用者のリクエストを模したアクセスが殺到してくるため,Webサービスの外形的な挙動を変えずに高速化することが求められます。

ISUCONは短い競技時間(大抵は8時間)の中で,初めて目にするWebサービスに対して大量に押し寄せるリクエストを処理しつつ,存在しているボトルネックを発見し,解消していく競技です。性能を改善すれば処理できるリクエスト数が増えてスコアが上がるようになっています。

ISUCONで最初に与えられるWebサービス(初期実装と呼ばれます)には,現実のWebサービスでもよくあるような性能問題が発生しやすい実装が多く含まれています。Webサービスから性能上の問題になるボトルネックを発見し,解消するという訓練になるのです。

ISUCONの知見が詰まった書籍で学ぶ

「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」は,ISUCONで出題されるようなWebサービスを例にして,実務でもよくあるボトルネックの特定,解決方法を学べる書籍です。

ISUCONは技術のコンテストですが,そこで題材として提供されるWebサービスは,通常のWebサービスと同様の技術で作られています。つまりISUCONでの高速化手法は,業務で作成されるような通常のWebサービスにも適用できるのです。

本書は,次のような方にお勧めします。

  • Webサービスを開発,運用しているが動作が重くて困っている
  • これまでWebサービスの速度について深く考えたことがなかった
  • ISUCONにこれから出場してみたい
  • ISUCONに出場したことはあるが,よい成績を収められなかった

前提として,基本的なWebサービスの概念は理解している方,なんらかのWebサービスを自分で作成できる知識を持っている方を対象にしています。

本書は,6名の執筆者で共著しています。執筆者陣は,多くの利用者に使われているWebサービスを開発,運用しており,その現場でパフォーマンスチューニングを実践してきたエンジニアです。また,ISUCONで何度も優勝したり,出題に携わった経験が豊富なエンジニアもいます。

実際の現場やISUCONでの知見を元にした,Webサービスを高速化するためのエッセンスが本書には詰まっています。

著者プロフィール

藤原俊一郎(ふじわらしゅんいちろう)

2011年より面白法人カヤック。技術部SREチームリーダー。ISUCON優勝4回,出題3回。最近の趣味はマネージドサービスの隙間を埋める隙間家具のようなツールをGoで作ってOSSにすること。著書に『みんなのGo言語[現場で使える実践テクニック]』(共著,技術評論社)。

Twitter:@fujiwara
URL:https://sfujiwara.hatenablog.com/