Ably Blogの先日の記事では、Alex Diaconu氏が、公開から13年を経た"eight fallacies of distributed computing (分散コンピューティングの8つの嘘)"を振り返るとともに、それらに対処するためのいくつかのヒントを紹介している。そのDiaconu氏に、Ablyのエンジニアたちがそれらの誤謬にどう対処しているのか、詳しく聞くことができた。
"eight fallacies"は、ソフトウェア開発を失敗に導く可能性のある、分散コンピューティングに関わる一連の誤謬(誤った考え方)だ。具体的には、"ネットワークは信頼できる"、"遅延はゼロである"、"帯域は無限である"、"ネットワークは安全である"、"トポロジは変化しない"、"管理者はひとりである"、"転送コストはゼロである"、"ネットワークは均一である"という仮定を指している。
これらの誤謬は、分散システムを設計する時に、責務とすべきアーキテクチャ上の要件として示される場合もある。InfoQは今回、そのDiaconu氏に、Ablyのエンジニアたちがそれらの誤謬にどう対処しているのか、詳しく聞くことができた。
InfoQ: "分散コンピューティングの嘘"が最初に提唱されてから13年近く経ちましたが、その重要性は今も変わっていません。御社では、どのような意味を持っているのでしょうか？
Diaconu: いずれも分散システム設計の落とし穴への指標であって、現在もなお重要なものばかりです。ただし、すべてが同じ影響力を持っている訳ではなく、比較的対処が容易なものもあります。Ablyのシステム構築方法に最も影響が行き渡っている誤謬は、次のものです。
- ネットワークは信頼できる。これは当然、すべてのサービスの設計と運用において考慮しなければならない面です。ネットワーク自体の信頼性が低いだけでなく、ネットワークを介して到達しようとするシステムに障害が発生する可能性もあります。さらに、ネットワークの信頼性は二値ではありません — 予期しないような障害に陥る可能性もあるのです。ノードや相互接続の障害を予測しておくことは、システム設計の本質的な部分です。これに対処する方法 — 例えばフォールトトレランス — については、Ablyのブログでも広く論じています。
- トポロジは変化しない。これは特に、当社のアーキテクチャに対する誤った考え方です。Ablyのプラットフォームはその時点での適応性を持つように設計されるので、トポロジは常に変化しています。そのため当社のシステムは、このトポロジの変化に定常的に対処しなければならず、これがシステムを複雑化させる大きな理由になっています。Ablyの中核システムは、リアルタイムに更新される共通のディスカバリ層の上に構築されています。他のシステムサービスはこのディスカバリ層を使って、システムトポロジに関する共通のビューを構築します。サービス間要求のルーティングはすべて、このトポロジのビューに基いて実施されます。Ablyサービスのスケールアップの過程においては、このディスカバリ層のスケーラビリティとパフォーマンスが、私たちが対処すべきエンジニアリング上の課題になっています。
- 帯域は無限であり、転送コストはゼロである。現実として、インフラシステムのネットワークコストは — 複数のリージョンに広がるグローバルなシステムでは — 運用コストの非常に大きな割合を占めています。従って、トラフィックがユーザロードの比例値を越えるような増加をしないシステム設計を行うと同時に、トラフィックを監視して、設計パラメータ以内に収まっていることを確認する必要があります。場合によっては、ネットワーク使用量の縮小が発生するという問題に突き当たることもあるので、このような縮小を検出するための監視も必要になります。
InfoQ: 過去13年、分散システムが進化する中で、考慮に値する新たな誤りが明らかになっていると思われますか？
Diaconu: 30年以上の歴史の中で最も重要な変化は、そのような誤りに対処する方法についての理解が成熟したことだと思います。対処が簡単になったとは言えませんが、理解は深まっています。よいアプローチ、悪いアプローチ、それぞれのアプローチの限界、といったものが分かってきました。これらの問題空間に関して、今は、確立された科学理論や工学的実践が存在しています。計算科学の学生たちは、問題とその最先端の解法を教えられます。
当然ながら、こういった誤りが永続性を持った技術的課題の現れである、という認識を持つことが重要です。安易に回避できる落とし穴と考えるべきではありません。実際に、"分散システムの誤謬を回避するのは容易いことだ"という、新たな誤謬が存在すると言ってもいいでしょう。
InfoQ: 誤った考え方のいくつかは、すでに当たり前のものになりました。例えば"クラウドは安全ではない"という考え方は広く受け入れられています。その一方で、それほど広く認知されていないために対処のプロセスが簡単でない、というものもあるのではないでしょうか。
Diaconu: すでに話したように、分散システムの抱える問題、構築に使われる技術やメカニズムに関わる広範な科学は、現在では十分に研究されています。しかしながら、現実世界においてこれらの問題に対処する上で学ぶべきなのは、学術的な理解には限界がある、ということです。
分散システムの構築にはエンジニアリングパラダイムやトレードオフが関わります。ベストソリューションは経験と実験を通じて見出されるものなのです。
例えば"ネットワークは信頼できる"という誤った考え方は、対処すべき最も基本的なものです。ソリューションとしては、懸念の対象とする障害モードに応じて、リトライを備えたプロトコル、合意形成プロトコル、フォールトトレランスのための冗長性、といったものが考えられるでしょう。
しかしながら、エンジニアリングの現実は、複数の種類の障害が、しかも同時に発生する可能性があるのです。したがって、理想的なソリューションは、障害の統計的分布や障害による損失の分析、エラーの発生による特定のサービスへの影響などによって決まることになります。
システムの信頼性が低ければ、リカバリメカニズム自体に障害が発生する可能性があります。このような障害の可能性も、ソリューションに影響を与えるでしょう。そしてもちろん、複雑性という危険もあります。理論的には正しいが複雑なソリューションは、理論上は不完全でもシンプルなソリューションと比較した場合、インシデント発生時の管理や理解がはるかに難しい可能性があるのです。
InfoQ: ここ数年で一般的なものになったマイクロサービスを見ると、"転送コストはゼロである"という誤った考え方とは対極にあるように思われます。事実として、個々のマイクロサービスが小さくなるほど、その数は増えて、転送コストは大きくなります。これはどういうことでしょう？
Diaconu: "マイクロサービスはシステムを理解しやすいものにする"という、別の誤った考え方があるのでしょう。表面積の小さなコンポーネントに分解することで、物事を理解しやすくなる場合はあります。しかしながら、境界が増えることによって複雑性が増す場合もあるのです。障害モードは明らかに増えますし、新たな事象が発生して、その挙動を理解する必要が生じるかも知れません。
先程の答と同じく、実際の設計選択や、既知の論理的ソリューションをいつどこに展開するのかは、エンジニアリングの判断と経験に帰着するのです。Ablyでは、拡張性と相互運用性を備えて、独立的にお互いを検出可能な、複数の役割を持つシステムを開発していますが、機能を特定の役割に分割するということは、特別な理由がない限り、ほとんど行っていません。例えば、他の機能とは独立的にスケールアップする機能が必要な場合であれば、それによって複雑性が増すことになったとしても、独立した役割を作ることが正当化されます。
Diaconu氏の記事は、誤謬の起源の単なる紹介に留まらず、それら誤謬に対処するテクニックやアプローチに関する有益なヒントを提供している。この話題に興味があるならば、一読をお勧めする。