CodeZine(コードジン)

特集ページ一覧

我々はなぜKubernetesを使うのか――クラウドネイティブ時代のアプリケーション開発【デブサミ2019】

【14-A-4】 Cloud Native時代における Docker / Kubernetes による開発

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

サービスメッシュ―マイクロサービスを観測するには

 マイクロサービスはここまでに見たような多くの利点を持つが、モノリスでは表面化しなかった課題も見えてくる。数百の単位で機能を分けることで課題となるのが、クラウドネイティブの定義4点目にもあった「可観測性」だ。Netflixの適用事例では、2014年の時点で500を超えるマイクロサービスが数珠つなぎになっていたといい、手動によるサービスの状態管理は現実的に不可能である。

 そこで用いられるアーキテクチャがサービスメッシュだ。通常のマイクロサービスは直接アプリケーション同士がデータを受け渡すが、サービスメッシュを適用すると、各サービスは必ずプロキシを通してつながるようになる(スライドP.22)。これにより各リクエストは管理されるようになり、マイクロサービス間の通信はプロキシによりモニタリングされ、観測可能な状態となる。アーキテクチャ上分離することで、サーキットブレーカー[2]やリトライ制御などの制御機構や、暗号化などのセキュリティ対応もプロキシに任せることができ、開発者が業務ロジックにのみ集中することができるというのも利点だ。加えて、個別のトラフィックを別の環境に流すような、いわゆるカナリアリリース[3]やブルーグリーンデプロイメント[4]の制御も、プロキシを通すことで容易になる。

スライドP.22:マイクロサービス間のやりとりにプロキシを介するのがサービスメッシュの特徴
スライドP.22:マイクロサービス間のやりとりにプロキシを介するのがサービスメッシュの特徴

[2] サーキットブレーカー:特定のサービス呼び出しが閾値を超えて失敗したら検知し、以後のリクエストに対しサービス呼び出しをせず即時エラーとする遮断機構。障害連鎖の防止などの役割を果たす

[3] カナリアリリース:一部のユーザーにのみ新機能を提供することで、試験的に本番運用してフィードバックを得るデプロイ手法

[4] ブルーグリーンデプロイメント:更新前と後のアプリケーションをそれぞれ個別の環境に配置しておき、更新後の内容に問題があった場合、即座に更新前環境へ向き先を変えることでロールバックできるようにするデプロイ手法

Dockerコンテナと、従来のVMとの違い

 これまで見てきたマイクロサービスやサービスメッシュを実践する環境は、従来のVMを適用することでも可能だが、一般にコンテナ型仮想化と呼ばれる手法がよく用いられる。その理由として、VMと異なりOSごとではなく機能単位での仮想化が可能となるため、起動・停止が高速でオーバーヘッドが少ないという利点が挙げられた。また、イメージのビルドを一度行えばどこでも動く「Build Once, Run Anywhere」という特長も流行の要因として大きいという。VMでもVMイメージは作れたが、それに比べイメージ化が非常に容易であるとされ、具体例をもとにした説明がなされた。

 イメージの作り方はいたってシンプルで、命令をすることによりレイヤーが重なっていく構造になっている。スライドP.36のように5つの命令を順に行えば、そのままレイヤーとなる。そして、作成したイメージは一度ビルドすれば他の環境でも動くことが保証される。

スライドP.36:命令をひとつずつ実行することで、定義がレイヤーとして重なっていくシンプルな構造
スライドP.36:命令をひとつずつ実行することで、定義がレイヤーとして重なっていくシンプルな構造

  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:【デブサミ2019】セッションレポート

もっと読む

著者プロフィール

  • 西野 大介(SOMPOホールディングス株式会社)(ニシノ ダイスケ)

     SOMPOホールディングス株式会社デジタル戦略部(SOMPO Digital Lab)勤務。損保ジャパン日本興亜グループにおける先進技術の研究開発を担当。過去には基幹システムの開発にも従事し、SoR/SoE双方の開発において幅広い経験を持つ。本業以外では、CodeZineの連載をはじめ、国内/海外...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5