沈まぬシステムの作り方

今回はですね、あなたの作ったアプリとかサイトが、せっかく人気になった！って思ったまさにその瞬間に、 アクセスが殺到してダウンしちゃう。そんなまあ悪夢みたいな状況をどうやって避けるか、っていうお話です。 沈まぬシステムを作るための、その設計思想の核心に迫っていきましょう。いやー、クリエイターなら誰だって、 自分の作ったものが大ヒットするのって夢見ますよね。でもその大成功が、 一瞬にして悪夢に変わっちゃうことがあるんです。一体どういうことなんでしょうか。 例えば、あなたのウェブサイトがSNSでバズったとしますよね。アクセスがもう爆発的に増えて、 やったー！と思った瞬間、画面が真っ白に。そう、最高の瞬間がなぜか最悪の事態を引き起こしちゃう。 これ一体どうしてなんでしょう。さて、じゃあ、この急に増えたアクセスにどう対応するか。 もっとパワーが必要だってなったとき、多くの人がまず最初に思いつくことってなんだと思いますか。 そこで選択肢が2つ出てきます。1つは、スケールアップ。これはまあ昔ながらというか、 今あるサーバーをもっと高性能で、ドデカいサーバー1台に置き換えるっていう方法ですね。でも今のクラウド設計では、 これとは全く逆の発想。スケールアウトっていう、たくさんの小さなサーバーでなんとかしようっていう戦略が主流になってるんです。 このスケールアップっていうアプローチは、とにかくパワフルなサーバーを1台ドーンと置いて、全部それで処理しちゃおって考え方です。 サービス全体をたった1本の、ものすごく太い柱で支えてるみたいなイメージですね。これ、一見シンプルでわかりやすいんですけど、 実はね、すっごく大きな弱点があるんです。そう、もしも、そのたった1本の巨大な柱であるサーバーが、 何かの理由でポキッと折れちゃったら、どうなるか。もうサービス全体がガラガラと崩れ落ちちゃうわけです。 これこそが単一障害点。英語でSPOF、スポフなんて言いますけど、システム設計で最も避けなきゃいけない状況なんですね。 じゃあ、その1本の太い柱に全部頼るんじゃなくて、どうするか。ここで視点をガラッと変えて、 たくさんの柱で建物を支えるっていう、現代のクラウド的な考え方、数で勝負するっていうアプローチを見ていきましょう。 はい、これがスケールアウトのアプローチです。1台のスーパーなサーバーじゃなくて、ごく普通の標準的なサーバーをたくさん並べて、 みんなで協力して支える。たくさんの柱で建物を支えるイメージですね。これなら、1本くらい柱が壊れても、まあ大丈夫そうですよね。 でもここで1つ、新しい問題が出てくるんです。お客さん、つまりアクセスがどんどんやってきたときに、 どの柱、つまりどのサーバーに案内すればいいのか。その交通整理、どうするのって話です。 そこで登場するのが、このロードバランサーです。こいつがまさにサーバーたちのための交通整理役をやってくれるんですね。 ユーザーからのリクエストを、はい、あなたはこちらのサーバーへ、あなたはあちらへどうぞって感じで、かしこく、そして公平に振り分けてくれるんです。 これで1台のサーバーだけに仕事が集中しちゃうなんてことを防いでくれるわけです。この図がすごくわかりやすいですよね。 左側のぐちゃっとしたアクセスが、入り口にいるロードバランサー、この交通整理役のおかげで、 右側のようにきれいに整列して、後ろに控えてるサーバーたちに均等に振り分けられていく。いや、見事ですよね。 これで特定のサーバーだけがパンクしちゃうのを防いで、システム全体をスムーズに動かし続けられるというわけなんです。 なるほど、サーバーをたくさん並べてロードバランサーを置けば、大量のアクセスはさばけると。でも、ちょっと待ってください。 もしそのサーバーのうちの1台が、突然壊れちゃったらどうなるんでしょう。そのサーバーに向かってたリクエストとか、 ユーザーは一体どうなっちゃうんでしょうか。そこで大事になってくるのが、高可用性、英語だとハイ・アベイラビリティ、 略してHAなんて言ったりしますけど、この考え方です。これは要するに、故障が起きることを前提として、 それでもシステムが止まらないようにうまく対処できる仕組みを、あらかじめ作っておこうっていう設計アプローチなんですね。 そのための鍵となるのが、フェイルオーバーっていう仕組みで、まさにシステムのセーフティネットですね。この図を見てください。 まず、普段は複数のサーバーが元気に動いてます。でも、ステップ2。1台が何かの問題でダウンしちゃった、その瞬間です。 ステップ3。トラフィックが即座に、自動的に他の元気なサーバーに切り替わる。これがフェイルオーバーです。 すごいのは、これユーザーはまったく気づかないうちにやってくれるってことなんです。 で、このいざという時のための予備サーバー、つまりスタンバイにも、実はいくつか種類があるんです。一番手厚いのがホットスタンバイ。 これはもう、常に電源オンで、データも最新の状態に保たれてるんで、瞬時に切り替えられます。ただ、まあ当然ですけど、コストは一番高い。 その逆が、コールドスタンバイ。普段は電源オフ。だからコストは安いけど、いざという時に起動から始まるんで、復旧に時間がかかっちゃう。 その中間にウォームスタンバイなんてのもあります。要は、システムの重要度に合わせて、このスピードとコストのバランスをどこにするか、選べるってことですね。 さて、ここまでで、サーバーをたくさん用意して、負荷を分散して、さらに予備も用意して、故障に備えるっていう話をしてきました。 じゃあ、これで完璧かというと、実はもう一つ、すごく大事なポイントがあるんです。 それは、これらのサーバーたちがお互いにべったり依存しすぎてたらどうなるの？ってことです。 一つ何かを変えたら他の全部に影響が出ちゃうみたいな、そういう複雑なシステムは避けたいですよね。そのための秘訣、キーワードが、 この疎結合です。疎結合と読みます。これは、システムの部品、つまりコンポーネント同士が、あんまりお互いのことを深く知らずに、 それぞれが独立して動けるように設計しましょうっていう考え方なんです。じゃあ、どうやって疎結合を実現するのか。 その鍵は、各パーツをブラックボックスにしちゃうことなんです。どういうことかというと、他の部品はそのブラックボックスの中身がどうなってるかなんて知らなくていい。 ただ、決められた窓口、つまりインターフェースを通して、これお願いってリクエストを送るだけ。 そうすれば、例えば一つの箱の中身を最新のものに入れ替えても、他の箱はまったく影響を受けないわけです。 まさにレゴブロックみたいにパーツを自由に取り替えられるようになるんですね。この疎結合をさらに推し進めるために、 サーバー自身はステートレス、つまり状態を持たないようにします。例えば、ユーザーのログイン情報とか、そういう個人的なデータをサーバーの中に直接置かないんです。 じゃあどこに置くのかっていうと、みんなが使える共有の保管場所、そうですね、イメージとしては共有のコインロッカーみたいな専門の場所にまとめて保存しておく。 こうすることで、どのサーバーも、いつでもどんなユーザーのリクエストにも対応できるようになる。これロードバランサーからすると、 めちゃくちゃ仕事がしやすくなるわけです。さあ、それでは最後に、これまで話してきた原則を全部組み合わせて、 沈まぬシステムの完成図を見てみることにしましょう。強くてしなやかなシステムの3つの柱、まとめるとこうなります。 まず第一に、たくさんの小さなサーバーで支えるスケールアウト。第二に、いざという時のための予備を用意して、単一障害点をなくす冗長性。 そして第三に、各部品が独立して動ける疎結合。この三つを組み合わせることで、どこか一つに問題が起きても、 システム全体としては止まらない。そんなパワフルで回復力の高いシステムができあがるんです。 つまりこれって、ただデカいサーバーを作るっていう話じゃないんです。もっと賢くて、何かあっても自分で直せるような、自己修復するシステムを組んでいくっていうことなんですね。 この考え方のシフトこそが、ただ成功に耐えるだけじゃなくて、成功を力に変えて、もっと成長していけるアプリを作るための鍵なんです。 さて、あなたのシステムは、その大ブレイクの準備、できていますか？