マイクロサービス関連技術は、コンテナオーケストレーションツール「Kubernetes」を土台に標準化が進んでいる。サービスメッシュの「Istio」、自動運用のための「Kubernetes Operator」、サーバーレスを実現する「K Native」などだ。今後のKubernetesの導入を見据え、経験値を高めよう。

 これまで、モノリシックなシステムを段階的にマイクロサービス化していくプロセスを説明してきました。最終回では、マイクロサービス関連技術の動向を踏まえて今後の進化を見ていきながら、現時点では何に取り組んでいくべきかを考えます。

Kubernetesがデファクトに

 Dockerをはじめとするコンテナ技術は、Linuxカーネルを土台にして、Linux上に構築されるミドルウエアやアプリケーションを抽象化します。アプリがどのような言語やミドルウエアで構築されていても、コンテナとしてビルドされていれば、全く同じものとして扱うことができます。システムが複数のコンテナで構成されている場合、それらのコンテナ群を一元的に管理する必要があります。これに有用なのがコンテナオーケストレーションツールです。

 この分野で注目されるのが「Kubernetes」です。Kubernetesは2014年にGoogleが発表し、2015年に「Cloud Native Computing Foundation(CNCF)」に寄贈する形でバージョン1.0がリリースされました。

 Kubernetesはグーグルが社内で利用していたコンテナ管理ツールを汎用化してオープンソース(OSS)化したものです。様々な企業が開発に参画しており、Googleが提供する「GKE(Google Kubernetes Engine)」のほか、Microsoft Azureの「AKS(Azure Kubernetes Service)」やAWSの「Amazon EKS(Amazon Elastic Kubernetes Service)」など様々なサービスが提供されています。この分野ではデファクトスタンダードと言ってよい状況です。Kubernetesが進化する方向はマイクロサービスの進化と重なるので、本記事でもKubernetesを中心に見ていきます。

コンテナ群を分散管理

 Kubernetesの仕組みを説明します(図1)。まず、コンテナ群全体を管理するためにMaster(マスター)と呼ばれるコントロールプレーンが存在します。Masterはコンテナのデプロイ先となる、Node(ノード)と呼ばれるサーバーを管理します。Node内にはPodという単位でデプロイを行います。Podは1個以上のコンテナをまとめたもので、ストレージボリュームやIPアドレスが付与されています。

図1●Kubernetesの仕組み
[画像のクリックで拡大表示]

 Dockerはアプリが稼働するために必要なミドルウエアの構築手順やアプリの起動手順を示しますが、Podはそのアプリが稼働するために必要なリソースの構成情報を含んでいます。簡単に言えば、Kubernetesはコンテナレジストリーからコンテナイメージを取得し、それをPodにまとめてNodeにデプロイします。

 Kubernetesは稼働すべきPodの台数を管理し、障害発生時に自動的にリカバリーを行ったり、Nodeの負荷状態に応じてPodのデプロイ先Nodeを調整したりします。Kubernetesは、こうした管理を実現するために、コンテナ群を集中管理するのではなく、分散管理しています。

 コンテナ群の構成情報はMaster内にあるetcdと呼ばれる分散型キーバリューストアで管理されていて、API Serverを通じて書き込みと読み出しが可能です。コンテナを管理するコンポーネントは、この構成情報を監視し、現状との差分を埋めるように動作します。これはDeclarative Configuration(宣言的設定)と呼ばれる考え方です。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら