← メディア一覧

サーバーダウンを防ぐ冗長化と疎結合

5分26秒 | ハードウェア基礎

基本情報技術者試験の頻出テーマを解説した音声コンテンツです。

トランスクリプト(字幕テキスト)

あなたのサイトがある日突然ものすごく人気になって、アクセスが100倍になったとします。 でも、サーバーがダウンしてしまって、画面は真っ白。こんな時、どうしますか? もっと高性能なサーバーに買い換えるしかないって思いますよね。ええ、多くの人がまずそう考えますね。 これっていわゆる垂直スケーリングっていう考え方なんですよね。そうです。 でも、その1台の最強サーバーにも限界はありますし、もしそれがたった1台が故障してしまったら、全部止まってしまう。 そこが怖いところです。ですよね。なので今回は、そのシステムの成長と障害にどう備えるか。 1台を強化する垂直の方法ではなくて、プロの世界で主流になっている水平に広げる考え方、 そして単一障害点をなくすための設計思想を深掘りしていきましょう。お願いします。 まずその垂直と水平の違いからですね。はい。サーバーのスペック、つまりCPUとかメモリを増強していくのが、 上に性能を伸ばすイメージで垂直スケーリング。それに対して、サーバーの台数を増やしていくのが、 横に広げていくイメージの水平スケーリング。こういう理解で合ってますか?その通りです。 完璧な理解ですね。で、それぞれのメリットデメリットですが、垂直スケーリングはやっぱり限界があるんですよ。 物理的な限界ですか?そうです。それにスペックを変更する時に、どうしてもシステムの停止が必要になることが多い。 一方で水平スケーリングは論理的には限界がありません。ほう。しかも、システムを止めずにサーバーを増やしていける。 だからこそ、今のクラウドの時代では、もうこちらが基本になってるわけです。なるほど。 数を増やす水平が主流と。でもあの、台数を増やしたら今度は来たアクセスを誰がどのサーバーに振り分けるか。 っていう新しい問題が生まれませんか?なんだか賢い交通整理員が必要になりそうですけど。まさに。 いいところに気づきましたね。その交通整理員が、ロードバランサーです。ロードバランサー。 はい。でも、もしですよ。その優秀な交通整理員が1人しかいなくて、急に体調を崩してしまったら。 ああ、交通は完全に麻痺しますね。そうなんです。それこそが我々が最も恐れるSPOF、単一障害点なんです。 スポフ。ここが壊れたら全部止まるっていう致命的な弱点。そのロードバランサー自体がSPOFになってしまうと。 そういうことです。じゃあ、その1人しかいない整理員問題、どうやって防ぐんですか? 答えは、実はすごくシンプルで、2人以上用意することです。あ、なるほど。 これを専門用語で冗長化と言います。サーバーもロードバランサーもデータベースも。 とにかく大事なものは全て複数用意しておく。これがもう鉄則中の鉄則ですね。冗長化ですか。 ええ。例えば、稼働率が90%のサーバーが1台あるとしますよね。はい。10%は止まる可能性があると。 そうです。でもこれを2台並べて冗長化すると、両方が同時にダウンしない限りサービスは止まらない。 その結果、全体の稼働率はどうなるかというと、99%になるんです。おお。 10%の停止確率がたった1%にまで減る。これは大きいですね。はい。 ただ、数を増やしただけではまだ不十分な場合もあるんです。と言いますと。 もし、システムの各機能が互いにガチガチに依存し合っていたらどうでしょう。 1つの小さな不具合が全体に波及して、結局共倒れしてしまうかもしれない。ああ、なるほど。 ドミノ倒しみたいに。まさに。そこで重要になるのが疎結合という設計思想です。疎結合ですか。 はい。例えるなら、レゴブロックみたいなものです。レゴブロック。ええ。 各ブロックは独立してますけど、ルールに従ってちゃんと組み合わせられますよね。 1つのブロックを別の色に変えても、作品全体が壊れたりはしない。確かに。 でもこれが接着剤でガチガチに固められたプラモデルだったら、一部だけを改造するのはすごく大変じゃないですか。 その状態が密結合なんです。なるほど。 システムをレゴブロックみたいに独立したパーツの集まりとして作っておけば、一部が壊れても他は動き続けるし、 パーツの交換も簡単だ。その通りです。今日の話をまとめると、急なアクセス増に対応するには、 まず1台を強化する垂直思考から、数を増やして負荷を分散させる水平思考へ転換することが重要です。はい。 そしてその鍵を握るのが、弱点であるスポフをなくすための冗長化、影響を限定するための疎結合。 この2つの設計思想にあるわけです。いや、よくわかりました。ありがとうございます。 最後に、ちょっと視点を広げてみたいんですが、今回はサーバー単位の障害について考えましたよね。 ええ。でももし、データセンター全体が例えば災害とかで使えなくなったらどうでしょう。 あなたのECサイトのデータが1つの地域にしか存在しなかったとしたら。あー、それは深刻な問題ですね。 ですよね。冗長化の考え方って、実は地理的なスケールにまで拡張して考える必要があるのかもしれませんね。 あなたのシステムは拠点レベルの障害まで想定できていますか?

このコンテンツは Web society で視聴・学習できます。