Kubernetesを利用したクラウドネイティブな開発と運用とは何か? これまでと何が違うのか? サイバーエージェント青山氏が語る(後編) July Tech Festa 2019

2020年2月18日

Kubernetesを利用したクラウドネイティブな開発や運用は、これまでとどう違うのでしょうか、あるいはどのくらい進化したものなのでしょうか。

2019年12月8日に産業技術大学院大学で行われたイベント「July Tech Festa 2019」で、サイバーエージェントの青山真也氏が行ったセッション『「Kubernetes による Cloud Native な開発」と「VM 時代の開発」』で、VMを用いた従来の方法と比較しつつ、Kubernetesを前提としたクラウドネイティブのやり方が分かりやすく紹介されています。

その内容をダイジェストで紹介しましょう。本記事は前編後編に分かれています。いまお読みの記事は後編です。

Kubernetesはロードバランサーも制御

ローリングアップデートでも密接に関わるロードバランサーの管理はどうでしょうか。

VMでは、VMの管理とは別に、ロードバランサーを管理するコードが別途必要になっていて、例えばVMを増やしたり減らしたりするときに、ロードバランサーと連動させるためのスクリプトなどが必要です。

しかもこの辺りはインフラエンジニアの領域になっていることが多いので、アプリエンジニアから依頼があって作業する感じでスピードもそれほど迅速でないことがあるかもしれません。

Kubernetesではロードバランサーも制御できるようになっています。

説明のために話を少し前に戻すと、Kubernetesはアプリケーションのデプロイを構成するDeplomentというファイルがあります。

そこでコンテナに特定のラベルを付与する設定を書くことができます。コンテナを3つ起動すると、それぞれにラベルを付けられます。

そしてロードバランサーを作るとき、スライドの右にあるServiceというリソースを別途作る。このマニフェストをKubernetesに登録すると、外部のロードバランサーと自動的に連携できるようになります。

そして、さっき説明したローリングアップデートで自動的にロードバランサーのメンバーを外したり追加したりしたように、コンテナを増やしても自動的にロードバランサーの配下になるようにKubernetesが運用してくれます。

そしてラベルが一致するアプリケーションに対してトラフィックを転送します。

fig14

細かい挙動によるヘルスチェックも可能

あるコンテナの障害時にはロードバランサーの転送先からいったん外すことになります。

そのためには、コンテナが正常に動作しているかどうかのヘルスチェックが必要です。

VMでのヘルスチェックでは細かい挙動までできませんが、Kubernetesでは、特定のパスに対してリクエストが届くかどうか、コンテナ内で任意のコマンドを実行して正しく返ってくるかどうか、などの動作をチェックできます。

fig15

こうしたKubernetesでのヘルスチェックではProbeと呼ばれる機能を使うのがほぼ必須になっています。つまり、Kubernetesを前提としたアプリケーションでは、そのためのエンドポイントを意識して作ることで、ある程度開発をレールに載せることになるため、副次的に品質が上がるという効果もあります。

IPアドレスも意識せずに管理できる

よく聞かれるのがIPアドレスについてです。

VMの場合、うちの会社でもだいたいそうですが、スプレッドシートにIPアドレスを書いて頑張って管理する。ちょっと自動化するにしてもChefで書いてリストで管理するとか。

IPアドレスの管理コストからはなかなか逃げられません。

これがKubernetesでは、IPアドレスを意識したら負けというか、そういうと言いすぎですが、IPアドレスを意識せずに管理することが可能になっています。

さっきKubernetesのServiceでロードバランサを作れますと言いましたが、そのロードバランサに対してリクエストするときに、通常はIPアドレスを使ってリクエストを送りますよね。

Kubernetesクラスタ内では、サービスの名前で内部のDNSが自動的に名前解決してくれます。なので、ロードバランサのIPアドレスは一切意識する必要がなくなります。

fig16

また、ロードバランサのメンバーもIPアドレスを管理する必要はなくて、コンテナにつけたラベルによってどのコンテナにリクエストを送るかが判別されるので、ここでもIPアドレスを意識せずにKubernetesに任せることができます。

つまりIPアドレスを意識せずとも、どういう名前にするか、どういうラベルにするかだけでサービス間の通信ができるようになっているのです。

グローバルIPアドレスや証明書の管理も

これはKubernetesのクラスタ内にコンテナが複数ある場合のコンテナ間の通信の話でした。

ではグローバルIPアドレスはどうなのか?

これはデフォルトのKubernetesの機能ではありませんが、External DNSという機能で、外部のロードバランサーが作られてグローバルIPが払い出されたあとで、この外部のロードバランサーに対してグローバルIPアドレスと特定のDNSレコードを結びつけるといったこともできます。

外部からのユーザーは特定のURLにリクエストを送ると、自動的にそこに結びつけられたIPアドレスに接続できるようになるのです。

これでグローバルIPアドレスの管理も必要なくなるというメリットがでてきます。

さらにcert-managerを利用すると、証明書も自動的にそのIPアドレスとかドメインに登録してくれたりとか、期限が来たら更新とか、そういうことも可能です。

Kubernetesでは証明書の管理とかIPアドレスの管理が抽象化されて、管理の手間を低減できます。

Kubernetesはつねにあるべき状態へ復旧する

次は障害時の話。

VMの場合、自動回復、セルフヒーリングはsystemdやsupervisordなどによる復旧に任せることが多いですね。それでだめなら人間が起きて対応すると。

Kubernetesでは自動復旧に関する仕組みが非常によくできています。

Kubernetesは、コンテナを起動するだけではなく、コンテナ群をあるべき状態にし続ける、というのがコアロジックになっています。

なにかが発生して状態が変わったとしても、「Reconcile Loop」によってあるべき状態に戻すのです。

例えば、コンテナを3つ起動するリソースを登録したら、登録したタイミングでコンテナが3つ起動するだけでなく、その状態をずっとキープする。

それをやってくれるのがControllerというプログラムで、Kubernetesのなかにはいろんな種類のControllerが用意されています。

Controllerは現状を認識(Observe)して、現状と理想の差分を確認(Diff)し、差異があったら理想に近づける(Act)というループ処理をずっと行っています。

fig17

例えば、3つのコンテナを起動するManifestを例にすると、万が一なにかの問題でコンテナが2つになったとき、理想は3で現実は2なので、差分として1つ足りないことを検知し、アクションとして1つコンテナを起動する。ということが内部で行われます。

Controllerは、人間がやっている運用の作業をプログラムとして自動化しているものといえます。

ステートフルなアプリが苦手とまでは言わないが

ステートフルなアプリケーションに関しては、VMのほうがライフサイクルが長いため、VMのほうが比較的向いています。

Kubernetesはステートフルなアプリケーションが苦手とまでは言いませんが、ステートフルなアプリケーションには向かないことが多いです。

アプリケーションごとに特化した運用の自動化を行うOperatorという仕組みがありますが、現時点で提供されているOperatorは、完成度は低くないものの完全に任せられるかというとそこまででもないので、もし検討されている方は注意深く検証するのがいいと思います。

Kubernetesを使うべきなのか?

では実際に、Kubernetesを使うべきなのでしょうか? こういった質問を唐突にされることもあるので、最後にそのお話をしたいと思います。

VMについてはすでに一般的な技術になっていて広く使われているので学習コストは少なく、既存のアプリを大きく変更する必要もありません。

ではKubernetesはというと、学習コストは高いとは思いませんが低くもありません。

このセッションで紹介したことは全体の20%くらいですので、さらにひとつひとつの機能を理解していく必要はあります。

ただし、さきほどKubernetesを使うとある程度レールに乗れるという話をしましたが、Kubernetesを学ぶことはCloud Native的なやり方のレールを学ぶことでもあります。

そしてそこで学んだことは、VMを使うときのアプリケーション開発や運用にも役に立つと思います。

fig18

冒頭で、VMでもクラウドネイティブな開発ができると言いましたが、Kubernetesを使わなくても、VMでも同じような方法論でアプリケーションをデリバリすることもできると思います。

Kubernetesを学びつつ、VMでその知識を活かしてもいいのではないでしょうか。

≫公開されているスライド『「Kubernetes による Cloud Native な開発」と「VM 時代の開発」July Tech Festa 2019』

このエントリーをはてなブックマークに追加
follow us in feedly




カテゴリ

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed


最新記事10本