はじめに
ソフトウェアアーキテクチャの基礎をぼちぼちと読み進めています。アーキテクチャの定義からはじまり、アーキテクトの役割、考え方、レイヤードにはじまるアーキテクチャの特性まで上手くまとめられています。アーキテクトを目指す方からすでにアーキテクトとして活躍されてる方、ほかにもシステム系管理職の方であれば読んで損はないかとおもいます。
職務上マイクロサービスについて顧客に説明する機会が多いのですが、分散アーキテクチャのポジティブな部分にスポットを当てた解説をすることが多く、逆にネガティブな部分については影になっていてあまり伝える機会がなかったりします。
”ソフトウェアアーキテクチャはトレードオフが全てだ”
著書にもあるように分散アーキテクチャの代名詞となってきているマイクロサービスにも当然トレードオフはあります。マイクロサービスとモノリシックのトレードオフの内容についてはたくさんのブログや記事で紹介されていますが、タイトルの「分散コンピューティングの誤謬」についても同著に記載があり、分散アーキテクチャの最初の課題群として1994年に定義されたものだそうです。誤謬とあるようにトレードオフの俎上に載らないことも多いため知見の開示と備忘録をかねて記事にまとめました。
目次
分散コンピューティングの８つの誤謬
誤診とは
1. ネットワークは信頼できる
- ソフトウェア アプリケーションは、ネットワーク エラーのエラー処理をほとんど行わずに作成されます。ネットワークの停止中、このようなアプリケーションは応答パケットを停止または無限に待機し、メモリやその他のリソースを永続的に消費する可能性があります。障害が発生したネットワークが利用可能になると、これらのアプリケーションは停止した操作の再試行に失敗するか、(手動で) 再起動する必要があります。
→いわゆる通信が届かない問題を考慮しましょうという話。モノリシックからマイクロサービスへシフトする際に無視されがちな印象。この可能性を完全に排除することは不可能なのでアプリケーション側でタイムアウトやサーキットブレイカー、結果整合性を意識した設計で回避していくしかない。
2. レイテンシーはゼロ
- ネットワーク遅延や、それが引き起こす可能性のあるパケットロスを無視すると、アプリケーション層とトランスポート層の開発者は無制限のトラフィックを許可し、ドロップされるパケットが大幅に増加し、帯域幅が浪費されます。
→ローカルでの呼び出しよりネットワークを介した呼び出しは必ず遅くなる。レイテンシーを予測、定義し制約を守っていく必要がある。これは一般的にはネットワークエンジニアが計測しSREと基準値を定める。複数のサービスを呼び合う複雑な構造になってくるとレイテンシーの予測は難しくなるのも注意。
3. 帯域幅は無限
- トラフィック送信側の帯域幅制限を無視すると、ボトルネックが発生する可能性があります。
→レイテンシーと似ているもののこちらはリソース的な観点。クラウドにリフトすることで無視されがちな課題でもある。プロジェクト規模によっては仕方ないこともあるが過剰なコンポーネント分解による無駄な通信を減らすためにDDDなどを用いて適切な粒度設計が必要。ただ、コンウェイの法則を無視すると運用複雑性があがるので冒険的ではあるものの逆コンウェイ的にリソースに見合う形でチームを再編するなども手段としてはありかもしれない。
4. ネットワークは安全
- ネットワークセキュリティに関する自己満足は、セキュリティ対策に継続的に適応する悪意のあるユーザーやプログラムによって不意を突かれることになります。
→クラウドへのリフトシフトで忘れられがちな問題。モダンな解決策としてはサービスメッシュと連携させたゼロトラスト構造などが挙げられる。既存アプリケーションのセッションをそのまま利用するのはよくあるアンチパターンなのでOIDCに則ったトークン認証などに変えていく必要がある。
5. トポロジーは決して変化しない
- ネットワーク トポロジーの変更は、帯域幅と遅延の問題の両方に影響を与える可能性があるため、同様の問題が発生する可能性があります。
→現場猫事案。とくにコンテナ間通信の手法を変更した場合などはトポロジーに大きな変化がおきる。DevOpsの体制とSREをもちいて向き合う課題。クラウドベンダのコンソールやk８sのマニフェストなど簡単にネットワーク部品を差し込めるのだからトポロジーは簡単に変化する。変化する前提となっている為、ただしく観測対象を把握して観測する。
6. 管理者は1人です
- 複数の管理者は、ライバル企業のサブネットと同様に、ネットワーク トラフィックの送信者が目的のパスを完了するために認識しなければならない競合するポリシーを設定する場合があります。
→これもプライベートクラウド事案。またはクラウドベンダー提供のGUIを操作できる人間が多いことで起きたりする。IAMをしっかり管理する。クラウドベンダーではインフラの設定変更の追跡を用いたカウンター的な対応を想定しておく。
7. 転送コストはゼロ
- ネットワークまたはサブネットを構築および維持するための「隠れた」コストは無視できないため、大幅な不足を避けるために予算に記載する必要があります。
→転送コストとあるが、どちらかというと通信に関して発生する部品やリソースのコストを指した話。分散アーキテクチャでは分散度に応じて機器類やセキュリティツールなどが増える為、いざやってみると意識してない部分でコストが増加しやすい。（MVPではじめてシフトが進むにつれて負担があがり結構怒られた記憶あり）
8. ネットワークは均一
- システムが同種のネットワークを想定している場合、最初の3つの誤謬から生じる同じ問題が発生する可能性があります。
→「6.管理者は1人です」と似た話。そもそもマルチクラウドやハイブリッドクラウドになってくると全く異質なものになる。k8sには別のクラスタ間を同一のものとして扱う機能があったりもするが、１番の対策は過観測性を確保して都度対策が取れる様にする。だと思う。OpenClusterManagamentやOpenshiftAdvancedClusterManagementなどを使うことで対策にできないだろうか。
まとめ
この８つの誤診が考えられた1994年のことを考えると、この誤診は今よりもはるかに影響の大きなものであったと思います。現代になって「ソフトウェアアーキテクチャの基礎」にて改めて挙げられた内容を見ても、影響度が下がった（または対策となるアーキテクチャやツールや考え方がうまれた）為、忘れたり無視されたりしがちですが本質的には今でも同じ問題を抱えており、これから分散アーキテクチャやマイクロサービスを始める場合はこの誤診を知っておくほうが良いと思います。