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と組み合わせる場合の制約やバージョン選択、その他コンフィギュレーションや構成要素の管理・監視設定など、専門のスキルと工数を要する作業が必要になります。このため十分に知見のある技術者を確保することが必要です」
サービス単体の可用性を確保するのに有効な2つのパターン
続いて早川氏は、Kubernetesでの可用性を考える上で必要な2つ目のポイント、「サービス単体の可用性の確保」に触れた。個々のサービスの観点では、モノリシックなアプリケーションに適用していた従来型の障害対策が有効だが、さらにKubernetesの機能を組み合わせることで、より高度な可用性構成が実現できる。
「まずは従来どおり、SPOF（Single Point of Failure）を生じさせないためにサービス内の構成要素を冗長化し、障害からの回復性を念頭に置いて設計します。そしてこれらを、Kubernetesの自律回復の機能を活用して実装していきます」
それらの実装例として、早川氏は以下の2つのパターンを紹介する。
【Replicated Database】MySQLの冗長構成＋自動再起動
- Kubernetesの「Service」オブジェクトの使い分けで、マスターおよびリードレプリカへのアクセスを適切にルーティングする。
- Kubernetesの「StatefulSet」を使って、データベースの自動再起動を実装する。
【死なないKafka】透過的に自律回復するクラスター
- オープンソースの分散メッセージングシステム「Apache Kafka」のBrokerをKubernetesに分散配置。
- Kubernetesの「Statefulset」とKafkaクラスターの自律調整機能を組み合わせて、障害時にもクライアントから見て透過的に自律回復する。
さらに早川氏は、「Kafka Brokerを使った構成は有効だが、本番運用を考えるとまだまだ克服すべき課題があります。例えば復旧時の負荷を考慮したサイジングが必要であることや、ノードやデータセンターごと停止するケースを想定して、ミッションクリティカルのシステムではインフラレベルの可用性を考慮しなくてはなりません」と付け加える。
ほとんどの機能がOSSで構成されているOracleのKubernetesマネージドサービス
さらに早川氏は、OracleがミッションクリティカルシステムにおけるKubernetes活用への解として、現在急ピッチで開発を進めている「Container Native Application Development Platform（CNP）」を紹介する。
CNPとは、Kubernetesと周辺ツールおよびフレームワークを一括提供するマネージドサービスだ。その特徴として、大きく以下の2つが挙げられる。
安全な運用と開発への専念を実現するマネージドサービス
CNPはKubernetesを中心としたコンテナベースの開発に必要な機能を網羅している。さらにそれらをアウト・オブ・ボックスで利用可能であり、開発者は基盤の構築管理から開放されてアプリケーションの可用性設計に専念できる。
また、ほとんどの機能をオープンソースソフトウェア（OSS）で構成しているため、ベンダーロックインを回避できる。
ミッションクリティカルな可用性を実現する基盤
障害復旧時の負荷に耐えるには、安定したパフォーマンスが必須要件となる。CNPはその実行基盤として、パフォーマンスと可用性に優れた、Oracleの第2世代IaaS（Oracle Cloud Infrastructure：OCI）を採用している。
OCIは高速SSDを搭載したベアメタル（非仮想）サーバーを採用しており、サーバー単体のパフォーマンスが非常に高い。さらに、3つのAvailability Domains（AD）によるデータセンターの冗長化と、AD間およびAD内のホスト間をつなぐ高速ネットワークにより、高い可用性と性能を両立する設計となっている。
CNPはこの次世代IaaSの力を生かして、大規模障害に耐える高可用性Kubernetesクラスターを提供する。
Oracleでは正式リリースに先立ち、すでにCNPの一部クラスターを公開しており、今すぐに体験できる環境が用意されているという。
「『Container Pipelines（Wercker）』『Apiary』『OCI（Oracle Cloud Infrastructure＝IaaS）』は、今すぐに使うことができます。またTerraformベースのKubernetesインストーラも公開済みです。ぜひ、Oracleの新しいプラットフォームを体験して、自社へのミッションクリティカルKubernetes導入に役立ててください」
最後に早川氏はこう語り、セッションを終えた。
お問い合わせ
日本オラクル株式会社
- TEL：0120-155-096（Oracle Direct）
- Oracle Cloud 詳細ページ
