パブリッククラウドの最適設計を考える
前述のように、パブリッククラウドやデータセンターには物理的にも論理的にも性能限界があります。では、パブリッククラウドにおける最適な設計とは何かを考えていきましょう。
図5は、2015年6月に開催されたQCON NewYorkで、Scaling Stack Overflowとして発表された資料の中で述べられたWebサイト「Stack Overflow」のリソース状況を示したものです。
HA Proxyが2台、Webサーバーが9台、SQLサーバーが4台など、そのリソース状況が示されるともに、ピーク性能が書かれています。
以前『いまさら聞けないクラウドのアレコレ（5）』の中でPinterest社におけるシステムエンジニア数の増加率とインスタンス数について解説しました。最初は3台だったPinterest社のインスタンス数が、翌年から85台、500台、1700台と増えていく姿は、いかにも北米のスタートアップ企業らしい成長を示しています。
先ほどのWebサイト「Stack Overflow」のリソース状況とPinterest社のインスタンス増加には、さまざま教訓が含まれています。これらを踏まえて、Webサービスが成長する段階を簡単に整理してみましょう。
図6は、Webサービスの成長とその推移を一般化・共通化し整理したいものです。たくさんのご意見が執筆している段階からでも手に取るように分かりますが、あえて基礎も基礎のMonothilicなWebサービス設計を取り上げます（Microservices設計好きの方は、ごめんなさい）。
Webサービスのトラフィックが増加して、その成長を遂げるにはいくつかの段階が考えられます。ここでは数台だったインスタンスが100台未満のインスタンスで構成されるまでの、Webサービスの成長について整理しています。SLB（Server Load Balancer）でトラフィックをさばき、Webサーバーおよびアプリケーションサーバーとデータベースが連携して、そのサービスを支える一般的な構成です。日本でインターネットが商用化されてから、まもなく四半世紀が経とうとしていますが、おそらくこのモデルが確立してから、現在に至るまで数多くのWebサービスの裏側で使われてきたシステム設計かと思います。
ここから得られる教訓には、ざまざまな知見が含まれています。1つ「Webサービスは止められない」、2つ「性能向上のためサーバーを動的に追加したい」、3つ「もっと高性能なサーバーを導入したい」など、運用上の条件が整理され、こういったシステム設計が生まれてきたと筆者は感じています。
では、Webサービスの成長とそれに必要なパブリッククラウドのリソースについて、さらに整理してみましょう。前述のように、データセンターにもパブリッククラウドにも物理的・論理的な性能限界があります。古くからあるデータセンターやパブリッククラウドであれば、SLB（Server Load Balancer）の性能限界が1Gigabit Ethernetの帯域に制限されている場合や、パブリッククラウド内部のLAN設計が10Gigabit Ethernet未満であるなど、さまざまな状況がパブリッククラウドごとに考えられます。
ここでは、これらの条件を一般化して「1つのWebサービスで、インスタンス数100台未満までは大丈夫かな……」という筆者なりの長年の経験と勘と仮説に基づいて整理をしています（ハズレていたらすみません）。
日本に存在する大企業・中小企業は51万社。そのうち10%の5万社がスケールアウトを必要とするWebサービスを展開すると想定します。ホスティングで十分にトラフィックをさばいている場合には、その限りではありませんが、そこからスケールアウト型のシステム構成へ移行するには、やはりある程度のサポート体制や支援が必要になります。前述のように100インスタンス未満であれば、ある程度テンプレート化されたシステム設計が用いられます。
しかし、それがさらに1000インスタンスを超え始めた段階で、さまざまな性能問題やシステム運用上の壁にあたり、システムエンジニアや経営を悩ませ始めます。この段階までスタートアップ企業が成長すると、それはシステムインテグレーションを伴うサポート体制や支援、場合によっては企業本体のシステム設計構築部隊を新設増強していくことになります（北米のスタートアップ企業の例でも、よく見られますね）。図7に、ここで解説した内容を図示してみました。頭の整理にお使いください。
「100インスタンス未満までのスケールアウトは、なんだかいけそうだ」そんな感触を持たれた方もいらっしゃるかと思います。また、「そのシステムは、もうやっています」という方もいらっしゃるとは思います。短いようで長いインターネットの歴史の中でシステムエンジニアのスキルセットも幅ができてきました。日本へ海外パブリッククラウドが上陸し、そのあと国産パブリッククラウドができ、さらにパブリッククラウド専門のシステムインテグレーターが出来上がって5年。私たちのシステム環境はさまざまな意味で変化しました。
パブリッククラウドが登場した当初は「北米と同じように、すべてセルフサービスだからシステムインテグレーションはなくなる！」という主張から「OS導入からシステム設計まで全部ボタンを1つクリックするだけでテンプレートからすべてができる！」など、本当にいろいろな表明・主張・うわさがありました（遠い目）。
その後、私たちを取り巻くクラウド・コンピューティング環境はどうなっていったか、読者の皆さまがいま感じられているとおりです。「OSは勝手に自動バージョンアップ」しませんし、「クリックだけでスケールアウトするWebサービス」はごく少数の企業で始まったに過ぎません。
とはいえ、前述までの整理から今でも「100インスタンス未満までのスケールアウトは、なんだかいけそうだ」という感触は共有いただけたかと思います。これでスケールアウト型Webサービス向けテンプレートが、さまざまな事業者から直接提供されるようになれば、より一歩未来へ前進できるのではと筆者は考えています。
冗長構成のためにインスタンスが立ち上がるゾーンが自動的に分けられ、SLB（Server Load Balancer）を隔てグローバルセグメントとプライベートセグメントが分かれ、インスタンスのプライベートIPアドレスが自動付与される。ある一定規模までサイトが増強されたなら、選択できるインスタンスが高性能なものに切り替わる。仕組みを手で動かそうとすると大変ですが、これがある程度決め打ちのテンプレートとして提供され、インスタンスの追加が容易にできたならば、それは本当にシステム設計と運用が楽になると筆者は感じています。
成熟したクラウド・コンピューティング市場において、今はまだないこういったサービスを、いずれ誰かが構築提供していってくれる日は近いかもしれません。最後にその期待を込めて図示して本稿を終わりたいと思います（図8）。
図を補足すると次のようになります。
- 最初からすべてが決め打ちのシステム構成
- インスタンスはすべてフラットなプライベートLAN上に配置され、互いのインスタンスは自由に通信できる
- インスタンス間の線は論理的なアプリケーション間の接続を示す
- インスタンスのゾーン配置は最初から冗長構成に配慮されている
- 稼働するインスタンスがある一定数を超えると、より高性能なインスタンスが選択肢に現れる
- データベースおよびアプリケーションサーバーのデータ同期・冗長化・フォールバックは、インスタンス内部のプログラムごとに完結する
旧来のスケールアウトを捨て、一気にスケールアップした別のインスタンスへ乗り換える。そんな選択肢も世の中にはありますが、選択できる高性能なインスタンスも論理的・物理的な限界を持っている以上、スケールアウト型の概念は、いましばらくは必要なのでしょう。
さてここまで、『いまさら聞けないクラウドのアレコレ（6）』と題して、私たちが置かれているIT産業の最前線を考察してきました。読者の皆さまに何か一つでもお役に立っていましたら幸いです。
