PaaSソリューションにとって、高可用性を維持するのは大変なことだ。ハードウエアだけでなく、ソフトウエアのインフラの可用性も常に確保しなければならないからだ。Mark McGranaghan氏はQCON Londonの発表(PDFスライドがダウンロードできる)で、HerokuでPaaSの可用性を確保するために使われているパターンを紹介した。
氏によれば、これらのパターンは2つに大別できる。
- 信頼できる設計コンセプトを利用するための設計に関するパターン
- 人とソフトウエアのやり取りを記述するソシオテクニカルなパターン
氏によれば、高可用性を必要とするアプリケーションを配置し運用する方法を考える場合、人間の動きがどのような影響を生むかは見積もれないことが多い。設計については、この発表で示された事例からもわかる通り、Erlangのコンセプトを取り入れている。
設計について
Heroku上のアプリケーションはHerokuの多くのサービスを利用でき、アプリケーションそのものはそれらのサービスを直接意識しなくて済む。例えば、HTTPリクエストのルーティングもそのようなサービスのひとつだ。実際にはアプリケーションはそのようなサービスを自ら使おうしても使えない。というのは、Heroku上のアプリケーションは複数のインスタンス上で動作し、インスタンスを再起動できる監視プログラムによって監視されているからだ。従って、アプリケーションは自分がどこで動いているかわからないが、Herokuのルーティング機構はアプリケーションが乗っているインスタンスがどこにあるか分かっているので、HTTPのトラフィックを振り向けることができる。ルーティング機構そのものも多くのクラウドインスタンスで構成され、必要に応じてスケールアウトや再起動ができるよう監視されている。このような仕組みはErlangのエラーカーネルというコンセプトに着想を得ている。すべてのサービスが監視されており、さらに監視プログラムも監視されている。どの構成要素が壊れても大丈夫なように設計されており、再起動もできる。これによって、HerokuもHeroku上のアプリケーションもエラー処理が容易になる。
どの構成要素が壊れても大丈夫なように設計してあるので、Heroku上のアプリケーションは耐障害性を備えていなければならない。氏はどのように耐障害性を確保するかについて例を示した。
信頼性の高いメッセージング
従来のメッセージ仲介アーキテクチャには単一障害点がある。つまり、メッセージの送り先であるエンドポイントが正常に動作しなければならない。Herokuは単一出版-複数購読型(publish one / subscribe many)と呼ばれるパターンを採用している。このパターンでは送信側は送信対象になりうる仲介者を複数知っている。他方、受信側はすべての仲介者を購読すればいい。このパターンによって、メッセージングシステムは個々の仲介者の障害に対する耐性を持つことができる。
メッセージ自体は単純なキーと値のペアだ。このペアは簡単に拡張できるので、停止時間無しでシステムの更新が行える。また、インスタンスの新しいバージョンの新しい属性が原因で互換性のない変更が発生する場合もあるが、古いインスタンスも新しいメッセージを正常に受け取り、問題なく動作する。
サービスの非可用性
データを読むサービスに依存するアプリケーションは、そのサービスが利用できない状態でも可能な限り動作し続けるべきだ。
あるサービスにデータを書き込む場合は、そのサービスが利用できない場合でもデータをバッファする。そして、サービスが利用できるようになったら、書き込み側は自動的に書き込み要求を再送信する。Herokuはほとんどのサービスを、データを送信する前にバッファリングする仕組みにしようとしている。このパターンは書き込み脱同期化と呼ばれている。
興味深いのはHerokuがバッファリング用に使っているのが、Doozerと呼ばれる彼ら独自の分散ストレージではなく、PostgreSQLだということだ。Mark氏によれば、PostgreSQLを使っているのは、限界が把握しやすく、Doozerにはない優れたツールと実績があるからだ。昨年11月に報じた通り、HerokuはHeroku上にないアプリケーションにもPostgreSQLを提供している。
続いてMark氏は"ソシオテクニカル"な側面について語った。
ソシオテクニカルな側面
人間とシステムとのやり取りを可能な限り簡単することは重要だ。人間とシステムとのやり取りがシステムの問題の原因であることは一般的だ。変更を受け付けるシステムであれば、当然、人間とのやり取りで大量の変更が発生する。
配置と新機能の展開
Herokuはカスタムのツールを使うことで配置をインクリメンタルに行っている。各配置は様々なステージで動作する。従来のステージは分離された環境だが、Herokuの場合は運用環境のインフラの一部がステージになっている。これらの部分は"内部"、"ベータ"、"全体"というように別けられている。新機能の展開も同じやり方に従っている。配置と同じように、機能フラグを使い運用環境の機能の有効無効を切り替える。このやり方によって、配置の展開と機能の展開を疎結合にできる。つまり、新しい配置を行い、従来と同じ機能を提供し、新しい機能は機能フラグを使って隠し、問題がないことが分かったら、新しい機能を順次有効にしていく。この方法だと問題点を簡単に局所化できる。
可視化
動的な部分を多く含むシステムの場合は特に監視が重要だ。Herokuは監視とアラートに大きな投資をし続けている。可視化にはとても大きな価値があるからだ。問題は警告によって検知する。例えば下記のような条件での警告だ。
- 99パーセンタイルのレイテンシ < 50
- アクティブなコネクション > 10
Mark氏は適切に警告を設定しておけば、機能停止についての警告を受け取れたかもしれない例を2つ示し、説明をした。
フィードバックの流れ
下流のコンポーネントの動作が関連するすべての要素に影響を与えてしまうのは分散システムの典型的な問題だ。Herokuの設計は耐障害性を確保したり、脱同期化を実施したりして、動作不良のコンポーネント対策をしているが、サブシステムが高負荷になるのを避ける仕組みもある。それが"フローコントロール"だ。ある種の処理の最大実行数が制限されており、その制限は実行中でも変更可能になっている。