AzureによるマネージドサービスとKubernetesエコシステムで“NoOps”を実現

NoOpsのためのKubernetesの機能

川崎氏はまず「NoOps」という言葉を「システムに自律的な運用能力（回復性）を持たせることで人間による運用を最小化することを目指すための継続的な活動」と定義。そこで得られるものとして、エンドユーザーにとっては高いサービスレベルなどを、運用担当者にとっては空いた時間を開発などに使えることなどを挙げた。

続いてNoOpsを実現するための3つの能力として、Self Healing（障害発生時に自動的に修復）、In-Flight Renewing（変更や更新などでの無停止メンテナンス）、Adaptive Scale（自律的リソース調整）を挙げた。

NoOpsを実現するための3つの能力

それをふまえて川崎氏は、回復性を持ったアプリケーションのためのKubernetesの機能の中から3つを紹介した。

1つめはSelf-Healingの仕組みで、コンテナやPodの状態を監視して、問題があった場合に自動的に再起動やサービスアウトをする。メカニズムとしては、ステートレスなアプリケーションを前提に、ReplicaSetの数をKubernetesが自動調整する。

KubernetesのSelf-Healing

2つめはIn-flight Renewingの仕組みで、同じDeployment配下のPodを段階的に入れかえるRolling Updateの機能を持っている。Kubernetes 1.7からは、ステートフルアプリケーションを扱うStatefulSetにおいてもRolllingUpdateがBetaサポートされた（Kubernetes 1.9で正式サポート）。

KubernetesのRolling Update

3つめはオートスケール。これにはPodのオートスケールとクラスタのオートスケールの2種類がある。PodのオートスケールについてはHorizontal Pod Autoscaler（HPA）が、クラスタのオートスケールについてはCluster Autoscaler（CA）が紹介された。

KubernetesのPodのオートスケール

Kubernetesのクラスタのオートスケール

マネージドサービスとKubernetesの連携

続いて、PaaSやサーバーレスなどのマネージドサービスについての話となった。「Kubernetesは強力だが、Kubernetesに向かないワークロードもあり、外のサービス使ったほうがよいケースもある」と川崎氏は言う。

氏は、オンプレミス、IaaS、PaaS、サーバレスを一般的な回復レベルで比較し、「ステートフルなワークロードなどKubernetesに向かないものは、プラットフォームとして回復性がネイティブ実装されたPaaSやサーバーレスを可能な限り選択すべき」と主張した。

このとき、Kubernetesと外部アプリケーションと連携をしやすくする仕組みとして、プラットフォーム非依存でサービスを利用可能にする「Open Service Broker API」と、KubernetesとOpen Service Broker APIを連携可能にする「Service Catalog」が挙げられた。

Open Service Broker APIは、もともとCloud Foundryで考えられたものを汎用化したもの。外部サービスのプロビジョニングや、更新・削除、バインディングなどを自動化できる。

Open Service Broker API

またService Catalogを使うと、KubernetesがService Brokerの外部サービスを簡単に利用できる。「簡単に言うと、kubectlから使えるようになる」と川崎氏は説明した。

Service Catalog

こうした分野について川崎氏は「Open Service Broker for Azure」も紹介した。簡単にKubernetesアプリからAzureサービスが利用できるようになるという。その利用イメージとしてService Catalog経由でMySQLサービスを利用する例が挙げられた。

Open Service Broker for Azure

Service Catalog経由でMySQLサービスを利用する例

マネージド型Kubernetesの利用

次にマネージド型Kubernetesについて川崎氏は語った。

そのメリットの一つが、マスターの可用性対応だ。ストレージ層の考慮、マスターコンポーネント、ワーカーノードとの通信など、「なかなか大変なので、どこかにオフロードしていきたいですよね？」と川崎氏。

Azureの場合は「AKS（Azure Container Services、その後Azure Kubernetes Serviceに改名）」が相当する。マスターの隠蔽とサービス化のほか、クラスタのアップブレードやクラスタのスケール変更などのオペレーションも簡単になるという。

AKS（Azure Kubernetes Service）

もうひとつ、コンテナを用意するだけで、サーバーやノード、クラスタを意識することなく使えるクラスタフリー＆サーバレスコンテナサービスについても川崎氏は語った。Azureの場合は「Azure Container Instances（ACI）」が相当する。KubernetesクラスタからコンテナをACIに直接展開することもでき、バッチのノードなどにも使えるという。

Azure Container Instances（ACI）

そのほか、Azureだけでなくさまざまな外部サービスをKubernetesから利用できるようにする「Virtual Kubelet」も紹介された。川崎氏は壇上で、Virtual Kubeletを起動して通常のノードと並んで表示されるところをデモした。

Virtual Kubelet

Virtual Kubeletが通常のノードと並んで表示される

マイクロサービスのためのKubernetesエコシステム

最後に川崎氏は、マイクロサービスのためのKubernetesエコシステムの活用について解説した。

マイクロサービスの課題として、データ一貫性・整合性や、複雑なサービス間通信、クライアント・アプリ間の通信、モニタリング、CI/CDなどがある。

特にサービス間通信は、通信の回復性や負荷分散、分散トレース、サービスバージョン管理など、いままで見えなかったものが出てくるという。

その解決策の1つがService Meshだ。ポイントは、Pod内にSidecarを埋め込むことで、コードを変更することなく回復性機能を追加することができる点だという。

Service Meshの代表としてIstioがある。Sidecarとして組み込んだ「Envoy」がプロキシーとして振る舞うため、コードの変更が不要だという。その例として川崎氏は、サーキットブレーカーの設定を紹介した。

Service Mesh

Service Meshの例：Istio

また、マイクロサービスのCI/CDの効率化については、Helmを川崎氏は挙げた。HelmはKubernetesアプリのパッケージ管理とデプロイメントのツールで、比喩としてはapt-getやyum、Homebrewのような位置づけだという。これによって、塊にまとめてパッケージ化したり、塊としてロールバックしたりできるという。