Posts tagged ‘Azure Kubernetes Service’
Kubernetes の導入時に考えるべきこと
Azure にシステム導入・移行するお客様に日頃ご支援をさせていただいているのですが、多くのお客様やエンジニアの皆様から、たびたび似たようなご質問を頂くので、その内容をここに紹介したいと思います。(実際、今日もとあるお客様で下記のご相談を頂いたので)
ご質問：
お客様からたびたび頂くご質問の例
- このシステムを Kubernetes (AKS) 上で構築するのは正しいですか？
- とあるコンサルから Kubernetes を導入しないと会社の未来はないと言われたのですが、本当ですか？
- 今、Azure Web App for Container か AKS (Kubernetes) の何れかの選択で悩んでいるのですが、どちらが良いですか？
- 今、このような Kubernetes(AKS) のシステム構成を考えているのですが、正しいですか？
質問の背景：
これらのご質問は、メッセージは異なるのですが基本的には同じ質問です。結局どのような場合に kubernetes (AKS) を活用するのが効果的なのかが理解出来ていないため出てくる質問です。
個人的には当たり前になっていたので、この手の内容はまとめなくても良いかな？と思っていたのですが、度々、お問い合わせを頂くので多くの方がお悩みなのかな？と思ったのと、今日ミーティングに同席された方から、ぜひまとめて欲しいとのご要望を承ったので書くことにしました。
ご質問いただいた際の私の対応：
このようなご質問をいただく際、私からは必ず、質問者に対して下記の２つを問い合わせます。
- そのシステムは変更の激しいシステムですか？例えば今後サービスの追加は多いですか？もしくは修正が多いですか？
- コンテナ化するサービスは大量の CPU やメモリのリソースを消費しますか？
Kubernetes を選択するか否か：
A. Kubernetes が適する場合
上記の質問に対する答えに対し、1 が「はい」、2 が「いいえ」 の条件を共に満たす場合は Kubernetes の導入が適するかと思います。(前提：アジャイル、DevOps などが出来る環境が整っている会社の場合)
1: はい (変更が激しい)
2: いいえ (大量の CPU/メモリは消費しない)
B. Kubernetes が適さない場合：
一方で、上記の質問に対する答えに対し、1 が「いいえ」、2 が「はい」の条件のどちらか片方でも条件を満たす場合は、Kubernetes の導入は適さないと思います。
1: いいえ (変更は激しくない)
2: はい (大量の CPU,メモリを消費する)
理由：
システムは変更の激しいシステムか否か
まず、1 の質問の背景はマイクロサービス化をしたいと考えるお客様に対しても同様の質問をするのですが、「変更」には２つの観点があります。一つは、「既存のサービスに対し頻繁な更新・バージョン・アップ」、そしてもう一つは「新機能の追加が多くある」です。
「既存のサービスに対し頻繁な更新・バージョン・アップ」が必要な場合、一早いサービスの入れ替えが必要になります。それを実現するためには、アジャイルでの開発を実践し、DevOps でビルドやリリースのパイプラインを自動化していきます。そして、古いバージョンから新しいバージョンに安全に入れ替えるために、ローリング・アップデートやブルー・グリーン・デプロイ、カナリー・デプロイなどの手法を用いて入れ替えていく必要があります。
その際、システム構築スピードであったり、構築やサービス入れ替えの容易性が重要になってきます。デプロイ先として IaaS を選ぶ場合、VM の構築には時間が掛かります。そして上記のようなローリング・アップグレードやブルー・グリーン・デプロイ、カナリー・デプロイなどの手法を取り入れるためには、ご自身でこれらを実現するための環境を整える必要があり多大な労力を伴います。
こうした手間や労力を軽減してくれるのが PaaS (Azure では Azure Web App)であったり Kubernetes(AKS) になります。
この時点では、まだ選択肢として PaaS, Kubernetes 何れもありうる状況ですが、次に考えるのがもう一つの「新機能の追加が多くある」か否かです。デプロイするサービス数が増えて来たり、サービス間の連携などが増えてくると、PaaS では管理が煩雑になる場合があります。その場合、Kubernetes クラスター内でまとめて管理をする方がサービス間の管理やサービス全体の運用管理が楽になったり見通しが楽になったりします。
具体的なサービスの追加数は、個々のシステムや企業における運用・管理ポリシーによって異なるので本来ならば明示は避けたい所ですが、追加するサービス数が 5-10 程度ならば、迷わず PaaS をお勧めします。
しかし、サービス数が、20を超えるようならば Kubernetes の導入をお勧めします。
もちろん、 5-10 程度でも Kubernetes をご利用いただいても良いかと思いますが、導入するサービス数に対して、運用・管理、さらに学習コストの方が高くつくのではないかと想定します。
CPU やメモリのリソースを消費するか否か
また、2 の稼働させるサービスは「大量の CPU やメモリのリソースを消費しますか？」についてですが、こちらも選択する際の重要な要素と考えています。
Kubernetes 上で稼働する Pod (コンテナを束ねた物) が実際にはどこで動いているのかを考えて頂くと納得していただけるのですが、Pod(コンテナ) は、実際には、Kubernetes クラスタのノード上で動いています。ノードは実際には １VM になります。例えば Kubernetes クラスタを 3 ノード (3 VM) で構成し、各ノードの VMに CPU 4 コア、16GB の VM を割り当てた場合を考えます。
この場合、３ノード全体で利用できる CPU やメモリーのリソースは下記の通りです。
CPU: 4 Core * 3 node = 12 Core(1200m)
Memory: 16 Gb * 3 node = 48 GB
自身が提供するサービスは、上記の 12 Core, 48 GB を超えてスケール・アウト（増やす）事は出来ません。実際には、Kubernetes を動作させるために必要な管理用の Pod(kube-system内のpod)で利用する CPU や Memory のリソースも含まれるため、上記の MAX 分までを自身のサービスを利用することも出来ません。
極端な例でわかりやすく説明すると、仮に自身が提供するサービスが 1 Pod (コンテナ) あたり CPU 1Core 分を消費するようなアプリケーションの場合、1ノードあたり 2 〜 3 Pod、トータルで 6 〜 10 pod 位しか作れないのです。また、1 Pod (コンテナ) あたり 2 GB 位メモリを消費するようなアプリの場合は、約 20 pod 位しか作れないことになります。
もし、CPU や メモリーを大量に消費するようなサービスを提供したい場合は、わざわざ Node の CPU やメモリを共有する Kubernetes 環境で提供するよりも、IaaS 環境で 1 VM に１サービスをデプロイして提供した方が、Kubernetes のオーバヘッドもなく、パフォーマンスも発揮するかと想定します。
つまり、Kubernetes で提供するサービスは、簡単にスケール・アウトしやすいサービスのデプロイには向いていますが、パフォーマンスを上げるためにスケール・アップが必要なサービスには向かないと考えています。
その場合、IaaS でも PaaS でも Serverless でも違う選択肢を考えた方が良いかと思います。
さいごに
Kubernetes は決して銀の弾丸ではないため、どうぞ適材・適所で稼働に向くサービスを稼働させるようにしてください。
JAPAN CONTAINERDAYS v18.12 での発表について
先日 JAPAN CONTAINERDAYS v18.12 に参加し 「40 Topic of Kubernetes in 40 Minutes」 という内容で 40 個の Kubernetes に関するトピックを 40 分でご紹介する内容を発表させていただきました。
1-16 のトピックについては当日はデモをしながら説明をしたのですが、参加してくださった方のお一人が具体的に私がどのようなデモをしたのかをまとめてくださっていました。（誠にありがとうございます。）
Topic 1-16 のまとめ記事はコチラ。
Container Days × kubernetes(k8s) × 「40 topic of kubernetes in 40 minutes」メモ
今回の私の発表内容には賛否両論があるかと思いますが、この内容は、2018 年 12 月の現時点で、私が私のお客様に対してお伝えする、Kubernetes(k8s) を本番環境に対して適用する際の注意ポイントをまとめた内容です。
まず、私の立ち位置を簡単にご紹介しますと、私は k8s の製品営業でも k8s の担当エンジニアでもございません。k8s の良さを理解しつつ、正しい所で正しく使っていただきたいと思っているエンジニアです。もし、提供するサービスが k8s にあっていなければ、違う方法を選択したほうが良いですよと私のお客様には言っています。そして、それによって扱うエンジニアが幸せになり、企業もより良いサービスを素早く提供していただきたいと考えています。
余談ですが、実話としてあるお客様から以前こんなご相談を受けました。
相談者：「寺田さん、御社では無い方からこのような事を言われまして」
某営業さん：「このシステムを将来的にコンテナ化し k8s を導入しないと駄目だ！将来がなくなる」
相談者：「えっ？えっ？」
相談者：「寺田さん、本当なんですか？」
寺田：「どのようなシステムなんですか？」
相談者：「こんなシステムで、今はこのような開発人員構成です」
寺田：「それなら、無理にしなくていいです」
最初に話を伺った際に、マジかこの営業？お客様を地獄の底に連れて行きたいのか？と思ったくらいでした。
k8s は確かに素晴らしいので、上手く使いこなせばとても大きな効果を得られます。しかし、扱い方を間違えると効果が得られないばかりでなく、余計管理コストは高くつき大変な思いをすることにもなるでしょう。
今回のイベント会場の懇親会会場でも別の方から、下記のようなご質問をいただきました。
「エンドのお客様がコンテナ化や k8s 化に期待しており、会社としてやらなければならないのだが、上司から今までと作り方もやり方は変えられない。」
寺田：「いえ、それコンテナ化してもメリット無いですよ！」
このようなやりとりは、今の日本に少なからずあると思うのです。k8s を導入したらそれだけで幸せになれると思っているのでしょうか？
まず、その場合に私が最初にお伺いするのは下記のような内容です。
「サービスは今後どのように成長して行きますか？」
「もっというならば、新機能の追加は今後数多くありますか？」
「作ったサービスの改良やバージョンアップは頻繁にありますか？」
共に YES ならば k8s を検討し始めても良いですし、そうでなければ違う道を模索して良いと思います。
実は、このセッションは私の、k8s を扱うまでの三部作シリーズの３本目のコンテンツになります。
1. 今後の開発ビジョン
2. Java on Kuberenetes on Azure
3. 40 Topic of Kuberenetes in 40 Minutes
1 に関しては、Kubernetesは銀の弾丸ではない――エンジニアが生き残るために必要な技術とは【デブサミ2018 関西】に発表内容がまとめられていますので、こちらをご参考にいただければと思います。k8s を扱うその前に、心構えであるとかバックグラウンドを説明したのがこちらです。
ポイントは、「どのような時に、そして何のために k8s を使うのか？」を考える事がとても重要だと言う事です。
実際に k8s を扱うにしても、出来る事は数多くあります、その際、この機能は必要？別のほうが簡単じゃない？管理が楽になるんじゃ無い？と思うならば、率先して違う手段も考えるのも良いと思います。いや、それでも k8s のここが便利だから使って、いち早くサービスを提供・展開したいと思って初めて、k8s を扱う土俵に立てるのだと思います。
こうした背景を踏まえて、三部作の３つ目として作成したのが今回のコンテンツでした。特に 26-33 の項目は、おそらく今まで誰も表立って触れてこなかった内容だと思いますので、あえてこの場を借りて発表しました。
時間の関係上、セッション中でも詳しい点をお伝えできなかった所もあるので、ここで真意も含めて共有したいと思いますが、長くなるので別エントリに分けます。
本エントリの続きはこちら
● 第２弾：Kubernetes を本番環境に適用するための Tips
寺田 佳央 - Yoshio Terada 