Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

サービスメッシュの「Istio」や、OSSで構成されたマネージドサービス――ミッションクリティカルなシステムをKubernetesで実現するカギはツールにあり!【デブサミ2018】

【16-C-4】Kubernetesでミッションクリティカル・システムを実現するための設計/実装ノウハウ

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/03/20 14:00

 コンテナ・オーケストレーション技術のデファクトとなりつつあるKubernetesは、エンタープライズ領域においても急速に導入が進んでおり、とりわけBtoCビジネスを展開する企業での需要が目立つ。一方でKubernetesの利用を前提とした場合、どのように設計/実装すればいいか、ベストプラクティスはいまだ出そろっていない。そうした課題に応えるべく、Oracleでは「高可用性」の観点からKubernetesにおけるアーキテクチャ設計/実装手法の研究に力を注いできたという。本セッションでは日本オラクルの早川博氏が、高可用性を実現する上で押さえるべき実装面での必須ポイントと、それらを前提に実現されるミッションクリティカルKubernetesのありかたを紹介。大規模かつ高可用性が求められるシステムを実現するには具体的にどうすればいいか、最新のノウハウが語られた。

目次
日本オラクル株式会社 クラウド・テクノロジー事業統括 セールスコンサルタント Cloud Native Developers JP 早川博氏
日本オラクル株式会社 クラウド・テクノロジー事業統括 セールスコンサルタント Cloud Native Developers JP 早川博氏

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と組み合わせる場合の制約やバージョン選択、その他コンフィギュレーションや構成要素の管理・監視設定など、専門のスキルと工数を要する作業が必要になります。このため十分に知見のある技術者を確保することが必要です」

Istioを導入する上で考慮するべきポイントとは?
Istioを導入する上で考慮するべきポイントとは?

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2018】セッションレポート

もっと読む

All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5