Kubernetesの可用性の要となる2つの重要ポイントとは？
早川氏は、Kubernetesで可用性を考えるポイントとして、「サービス境界」と「サービス単体」の2つの観点を挙げる。ご承知の通りKubernetesは個々のサービスを連携させるオーケストレーションツールだ。したがって、今回ミッションクリティカルの実装における可用性を考えるにあたっても、マイクロサービス・アーキテクチャを前提としていく。
そもそもサービス境界の問題とは、どういうことだろうか。マイクロサービスは、互いに疎結合なサービス同士が連携して全体を構成している。この連携の境界地点で発生する問題が「サービス境界の問題」である。ここが重要なのは、サービス同士の依存関係によっては、1カ所の障害が広範囲に波及する可能性もあるからだ。
例えば、サービスAとサービスBの2つが連携している場合、（1）サービスBで障害が発生→（2）サービスA側に、サービスBからの応答待ちのリクエストが累積→（3）応答待ちリクエストがAのリソースを占有してAも停止→（4）Bがアクセス集中で復旧困難に陥り、Bに依存する他のサービスもA同様に次々に停止……といった障害の連鎖があっという間に広がっていく。サービス単体の機能が担保されるのはもちろん大事だが、それらをつなぐサービス境界も同様に、マイクロサービス全体の可用性を担っていることがわかる。
ではサービス境界の障害の連鎖が広範囲に広がるのを防ぐには、どうするべきなのだろうか。
「有効な対策の一つが、サーキットブレーカーです。このサーキットブレーカーを2つのサービス間に置いて、サービス呼び出しに対する応答に異常を発見すると、それ以降の呼び出しを遮断する仕組みです」
こうすれば、異常発生時には呼び出し元のサービスに早期にエラーが返されるため、呼び出し元のリソースの占有を回避して、システムの稼働を維持しながら障害発生部分のサービス復旧を進めることが可能になる。
サービス境界の障害解消にサービスメッシュ＝「Istio」が有効
では実際に、サーキットブレーカーを導入する場合はどのように進めたらいいだろうか。早川氏は「境界に配置するだけなら簡単に見えるが、実際にはかなりの手間とスキルを要求されるため、自力で実装・運用するには工数もコストも相応にかかります」と語る。
また、サービス境界の問題と対処法は、上記の例（サーキットブレーカー）以外にも多くの項目があり、すべてに自力で対処するのは困難だ。サービス境界の問題の代表的なものとして早川氏は下の4つの項目を挙げており、これらを含むすべてに自社で的確に処置するのは困難を伴う。
- （1）サービス間通信の一時的な障害に対する再試行
- （2）正常に可動していないサービスの応答をムダに待ってしまうことでリソースを浪費することを防止
- （3）障害の影響がサービス機能全体に波及しないように、サービス群を適切に隔離
- （4）複数サービスにまたがるデータ更新の結果整合性の保証
これを解決するのが「サービスメッシュ」の考え方だと早川氏は話す。
サービスメッシュとは、個々のサービス間の通信を仲介するネットワークインフラストラクチャのレイヤだ。これを置くことで、数多くのサービス間の通信における、セキュリティの適用、ポリシー管理、さらにフェイルオーバーといった処理を統合的に実⾏し、サービス全体の運用を最適化しながら維持する。
サービスメッシュ機能を提供するソフトウェアの中でも、最近多くの注目を集めているのが「Istio」だ。これはGoogle、IBM、Lyftによって開発され、2017年5月にオープンソース化されている。
「Istioは、サービスメッシュのツールとして、サービス境界の問題の多くを解決できることが知られています。上で挙げた4つの「対処すべき課題」の（1）～（3）までは、Istioによって的確に対処できます」
Istioの特長の一つが「アプリケーションに影響なく、サービス境界の障害対策を導入できる」点だ。IstioではEnvoyと呼ばれるプロキシソフトウェアをそれぞれのマイクロサービス上に配置し、これらのEnvoyがネットワークトラフィックを仲介してサーキットブレーカーなどの機能を担う。
「Istioを導入する際には、Kubernetesと組み合わせる場合の制約やバージョン選択、その他コンフィギュレーションや構成要素の管理・監視設定など、専門のスキルと工数を要する作業が必要になります。このため十分に知見のある技術者を確保することが必要です」
