Skip to main content Skip to Footer

Blog - Cloud ComputingCommentary from our cloud experts around the globeBLOG アクセンチュア・ クラウド・ ダイアリーズ

May 22, 2018
Microsoft Azure におけるコンテナオーケストレーションツール Kubernetes の導入方針
By: 鈴木章太郎

アクセンチュアでテクノロジーコンサルティングを担当しているシニア・マネジャーの鈴木章太郎です。テクノロジーアーキテクトとして、主に、各社パブリッククラウド(AWS/Azure/GCP)上での、モバイル及び XR(VR/AR/MR) アプリ開発、AI 基盤構築、マイクロサービス基盤構築、DevOps アドバイザー等々、最新テクノロジー・開発手法等の適用を通じたお客様の業務改革を支援しています。

コンテナ化のメリット
皆様、Docker はご存じかと思います。これは、Docker 社が提供する Linux 用のコンテナ管理ソフトウェアです。

コンテナを実現する「コンテナ管理ソフトウェア」は、いわゆる"サーバー仮想化"を実現する方法の一つとして位置付けられます。
一つの OS にコンテナと言われる、独立したサーバーと同様の振る舞いをする区画を複数作り、それを個別のユーザーやサービスに割り当てるわけです。その結果、利用するユーザーやサービスから見れば、あたかも独立した個別サーバーのように感じられ、別々のサーバーが動いているように見える点は、ハイパーバイザを使う場合と同様になります。

しかし、同じ OS 上で実現するので、全てのコンテナは同じ OS しか使えません。
一方で、コンテナは、ハイパーバイザのように、個別にCPUやメモリ、ストレージなどを割り当てる必要がないので、システム資源のオーバーヘッド(仮想化のために割り当てられる資源や能力)が少なくて済みます。そのため、同じ性能のハードウェアであれば、より多くのコンテナを作ることができるわけです。

また、コンテナは、それを起動させるために、ハイパーバイザ型のように仮想マシンと OS を起動させる手間がかからないため、極めて高速で起動できます。さらに、ハイパーバイザのように仮想マシンごとに OS を用意する必要がないので、ディスク使用量も少なくて済むのです。
この時、ひとつのコンテナは、OS から見るとひとつのプロセスとみなされます。プロセスとは、プログラムが動いている状態を示します。そのため、他のサーバーにコンテナを移動させて動かすにあたっても、OS 上で動くプログラムを移動させるのと同様に、元となるハードウェアの機能や設定に影響を受けることが少ないというメリットがあるわけです。


従来のサーバー構成

Docker の特長として一つ挙げられるのは、コンテナを生成する設定を "Dockerfile" として公開し、それを他のユーザーと共有できる仕組みを設けたことです。これにより、他のユーザーが作ったソフトウェアとそれを動かすソフトウェア構築プロセスをそのまま他のサーバーで実行し、同じコンテナを労せずして自分のサーバー上で実現して、ソフトウェアをインストールできるようになったわけです。ハイブリッドクラウドやマルチクラウドといった利用形態に於いては、大変便利な仕組みですよね。このような特長から、Docker は、Microsoft、AWS、Google などのクラウド・サービス・プロバイダーをはじめ、VMware、IBM、Dell、RedHat などの大手 IT ベンダーが採用しています。

当該システムにおいてコンテナを利用するデメリットや注意点
もっとも、当該システムにおいては、コンテナが必ずしも最適な選択でない場合もありますので、下記の表の例のように、アプリケーションのアーキテクチャーを策定する際に、各分類の項目の要件から、詳細に検討していく必要があります。

# 分類 詳細 システム適用における検討
1 可用性 コンテナを動かすための基盤(docker)やレジストリなど必要なコンポーネントが増えることで障害ポイントが増える。 Docker については Kubernetes 等を採用することで冗長化を行う。レジストリは可用性とセキュリティを考慮し、冗長化してパブリッククラウド内のプライベートなネットワークに用意する。
2 セキュリティ コンテナイメージにバックドアやセキュリティホールを入れられるリスクがある。 十分な実績のある公式のイメージか、一からコンテナイメージを作成する。
3 セキュリティ レジストリ上に格納されているコンテナイメージを差し替えられるなどして攻撃が行われるリスクがある。 公開レジストリは使用せず、本システム利用者のみがアクセスできるプライベートレジストリを利用する。
4 セキュリティ コンテナイメージにセンシティブな情報(本番環境 API Key 等)を格納した場合、本場に外の環境から情報が漏洩する可能性がある。 センシティブな情報はコンテナイメージに含めず、環境変数などコンテナ外部で設定する。
5 運用 コンテナを動かすための基盤(docker)やレジストリなど必要なコンポーネントが増えることでシステムの状況把握の難易度が向上する。 システムとしては各コンポーネント(dockerやレジストリ)を監視対象に追加して障害発生ポイントの把握をしやすくし、必要以上にコンポーネントを導入しないなど複雑化しないように努める。
6 性能 アプリケーション/MW と OS の上にコンテナレイヤーが追加されることで性能ダウンが発生する(特にI/O)。 I/O性能が求められるアプリケーション/MWはコンテナ化しない。
※DB はコンテナ化せず PaaS を利用する、など。

コンテナのオーケストレーションの必要性と Kubernetes の登場

このように、コンテナ技術の導入により、各アプリケーションのデプロイは圧倒的に早く、自動的に行えるようになりました。Docker により、アプリケーションのコード、インフラの構成情報を統合的に管理(疎結合)することができます。
ただし、大規模なシステムの場合、複数のホストマシンからなる分散環境構築が必要です。開発したアプリケーションを、どのように効率よく継続的にデプロイしていくか?という開発 / 運用を考えなくてはならないわけです。また、実際の運用では複数のアプリケーションを連動させて一つのサービスとして提供する必要があります(例:マイクロサービスの開発)。
そこで、コンテナ間の連携が不可欠となりますし、障害時の対策など運用面を考慮した場合、複数コンテナを管理する、コンテナのオーケストレーションツールが必要となってきます。
このようなコンテナのオーケストレーションツールには、Docker Swarm, Apache Mesos/Marathon、そして Kubernetes 等いろいろありますが、現在、AWS、Microsoft、Google、IBM、等の主要クラウドベンダーが挙って CNCF の会員になり、現在のところコンテナオーケストレーションツールとして Kubernetes はデファクトといえる存在になりつつあります。

Kubernetes とは
Kubernetes は、ギリシャ語で “船の操縦手” “統括者・支配者” という意味です。
一般的には、K8s と略されて記述される事が多いです(K から s の間の文字数が8だから)。
ベアメタルサーバーや、仮想マシン(オンプレミス、クラウド)上の、 Docker をはじめとするコンテナ群を管理するシステム(コンテナオーケストレーションツール)の一つです。

Kubernetes は、Google 社内で開発/運用されていたコンテナクラスタ管理システム "Borg" のノウハウを結集して開発されました。現在は、CNCF が管理し Apache ライセンスで配布されている OSS(オープンソースソフトウェア)となりました。Kubernetes は、マイクロサービスを効率的にデプロイ、アップデートする諸機能を持ってます。例えば、コンテナのオートスケールや、Blue Green Deployment、Rolling Update、等の諸機能を備えています。
https://kubernetes.io/

Kubernetes

Azure における Kubernetes のデプロイにおける導入方針
さて、今回は「Azure への Kubernetes のデプロイ」を例にとってご説明したいと思います。その理由は、他のクラウドに比べて、コンテナオーケストレーションツールの選択肢が多いためです。
実案件でコンサルティングの後、Azure 上のデジタルプラットフォーム開発のフェーズで、この Kubernetes を使ったコンテナオーケストレーションツールを導入する必要が生じた際は、どのように導入方針を立てれば良いのでしょうか?

Azure のポータルを見ると、現在、
① Container Service
② Azure Kubernetes Service(AKS) (プレビュー)
その他のコンポーネントとして、Azure Container Instance、Azure Container Registry 等が使えるようになっています。 このうち、Azure Container Instance と Azure Container Registry は別の用途のものなのでここでは置いておいて、あと2つの選択肢が、
③ Kubernetes をそのままインストールする
④ ACS-Engine を使って Kubernetes をインストールする
という構成・方式です。ACS-Engine は、GitHub に公開されたデプロイ用のテンプレートになります。
https://github.com/Azure/acs-engine
https://github.com/Azure/acs-engine/releases/tag/v0.10.0

それぞれの構成・方式の違い
この①~④を比較しながら、現時点(2018年5月時点)での実案件での選択肢として最も適当なものを検討していく必要があります。

まず、①から見てみましょう。
① Container Service

概要
(このサービスセットアップ時に、他のコンテナオーケストレーションツールも選択可能ですが)Kubernetes をコンテナのオーケストレーションツールとして選択し、Azure 上のサービスである、Container Service を利用して、デプロイして使用する、というものです。


メリット

  • Azure 上のサービスなため Azure がマスターサーバー(IaaS)などを管理することで一定程度運用負担が軽減される
  • コンテナが動くサーバー(ゲストサーバー、IaaS)の管理を Azure に任せることで運用負担が軽減される

デメリット

  • ベンダーロックインが一部発生する
  • AKS がGA 次第、終了予定である(Azure のWebサイト内に明記されている)
  • マスターサーバー(IaaS)の管理は可能だが、メンテナンスは Azure が行うため、初期化される可能性もあり、カスタマイズが行えない
  • ネットワーク構成がある程度決まっており、例えば VNETの Subnet 等に柔軟に配置することができない

ということで、
評価

  • Azure 上のサービスのため一定の制約があり、本件では特にネットワークポリシーの制約のため、構成が複雑なものになりがちなため、採用するメリットが小さい。
  • AKS が GA 次第、終了予定のため採用し難い。
    ということになります。

次に、②を見てみましょう。
② Azure Kubernetes Service(AKS) (プレビュー)
概要
(このサービスセットアップ時に、他のコンテナオーケストレーションツールも選択可能ですが)Kubernetes をコンテナのオーケストレーションツールとして選択し、Azure のマネージドサービスである、Azure Kubernetes Service(AKS) (プレビュー) を利用して、デプロイして使用する、というものです。


メリット

  • マネージドサービスなため、マスターサーバー(IaaS) が立ち上がることなく、Azure が管理しユーザーからは見えず、運用負担がさらに軽減される
  • 立ち上がるサーバー数は少なく、コストが大幅に逓減される
  • 仮想ネットワークで通信不可も軽減される
  • ウイルススキャンも Azure 側でやってくれる

デメリット

  • ベンダーロックインが一部発生する
  • マスターサーバーの管理は Azure が行う(ユーザーはマスターサーバーの管理はできない)
  • ネットワーク構成は、柔軟に設定可能で、VNETの Subnet に配置することができる

ということで、
評価

  • Azure 上のマネージドサービスとして理想的であるも、プレビューのサービスであり、現時点(2018年5月)での提案では、採用し難い。
  • GA (一般向け提供開始) された場合、他の方式からこの方式に移行することができる。
  • 移行には、Microsoft から何らかの移行ツールが用意される見込み ということになるでしょうか。


さて次に、③です。
③ Kubernetes をそのままインストールする
これは、

  • Kubernetes をコンテナのオーケストレーションツールとして、そのままデプロイして使用する というものになります。


メリット

  • Kubernetes がベンダーフリーな技術のため、Azure 以外でも利用することができる
  • ② Azure Kubernetes Service(AKS) (プレビュー) への移行が楽に行える
  • ネットワーク構成は、柔軟に設定可能で、VNETの Subnet にも配置することができる

デメリット

  • マスターサーバー(IaaS)1-3台と LoadBalancer が追加になるためコスト増
  • K8s のアップデートなど運用における負担増

以上から、
評価

  • 現実的な選択肢だが、後述の④の方が、Microsoft が GitHub に用意したテンプレートを利用できるため、現在の提案においては④がより良い方式と判断。
    としました。


最後に、
④ ACS-Engine を使って Kubernetes をインストールする
という方式です。
こちらは、

  • Kubernetes をコンテナのオーケストレーションツールとして、そのままデプロイして使用する
  • その際に Microsoft が GitHub に用意したテンプレートである ACS-Engine を使用する というものになります。


メリット

  • Kubernetes がベンダーフリーな技術のため、Azure 以外でも利用することができる
  • ② Azure Kubernetes Service(AKS) (プレビュー) への移行が楽に行える
  • ネットワーク構成は、柔軟に設定可能で、VNETの Subnet にも配置することができる
  • ACS Engine はテンプレートであり、Kubernetesのデプロイを容易にするサポートができる


デメリット

  • マスターサーバー(IaaS)1-3台と LB が追加になるためコスト増
  • K8s のアップデートなど運用における負担増


ということで、
評価

  • 現段階での提案では、各ノードの管理が可能であること、柔軟なネットワーク構成が可能なこと等から、この Kubernetes + Azure Container Service Engine の採用が本システムでは適していると判断。 という形になりました。


選択のポイント
以上のように、Azure においてはいくつかの選択肢から要件を吟味して選択する必要があります。その際に、やはり GA (一般向け提供開始)がされていないものを、PoC でない案件で選ぶことができない場合が多いでしょう。そこで、その他の選択肢の中から選んでいくことになりますが、Container Service はディスコンが決定していることと、ネットワーク構成における柔軟性が無いことから、現時点で選ぶことはあまりなさそうです。したがって、③か④を選択しておいて、②の AKS に移行する、というのが現時点でのベストな構成かと思われます(最も移行の SI は別途検討する必要があります)。

こちらを参考までに、ぜひ皆様も、実際に手を動かして、技術検証などしてみて戴ければと思います。

Popular Tags

    最新の記事

      アーカイブ