ガーデニングと同様に、ソフトウェア開発でも、さまざまな要素がどのように連携して、美しく生産性の高いエコシステムを生み出すのかを理解する必要があります。そこで、今年の「Microservices March」プログラムでは、ガーデニングをテーマに選びました。しかし、どの庭にも厄介な雑草が生えるように、議論の中で繰り返し浮上する疑問があります。それは、マイクロサービスとKubernetesの違いは何か、ということです。

植物は、庭の生態系を構成する主要な要素です。庭を形作る生物として、その美しさと機能性を支えています。同様に、マイクロサービスは、最新のソフトウェアアプリケーションを構成する主要な要素です。個々のサービスが特定の機能を担い、連携することで、より大規模で複雑なアプリケーションを構築します。
植物と同様に、マイクロサービスも規模、形態、目的はさまざまです。単一の処理を担う、小規模で特化したものもあれば、より大規模で汎用的な処理を行うものや、小さなコンポーネントを組み合わせて構成されるものもあります。たとえば、イチゴは小さな植物で、実るのはイチゴだけです。これは、クレジットカード取引の処理だけを行う、小規模で特化したマイクロサービスに似ています。一方、パクチーのように用途が広い植物からは、サルサやワカモレに使われる葉だけでなく、コリアンダーシードも採れます。このような植物は、ユーザー認証を処理する、より大規模で汎用的なサービスに似ています。

ほとんどの植物は、養分と水分を吸収できるよう土に植える必要があります。根がむき出しのままでは枯れてしまいます。地面に直接植えてもまったく問題ありませんが、鉢を使ったコンテナガーデニングを選ぶ園芸家も少なくありません。土を植物に合わせて調整し、害虫から守りやすくできるほか、庭の中で植物を移動したり、冬には屋内へ取り込んだりできるためです。同様に、マイクロサービスの配置先にも複数の選択肢があり、最も一般的なのが、その名のとおり「コンテナ」です。コンテナ化されたマイクロサービスには、アプリの実行に必要なものがすべて含まれており、実行環境間で容易に移行できます。

さて、マイクロサービス(植物)をコンテナ(鉢)に収めましたが、これらをどのようにデプロイ、保守、スケーリングすればよいのでしょうか。そこで必要になるのがツールです。ここで登場するのがKubernetesです。Kubernetesには、マイクロサービスの管理と保守を容易にする多くの機能やアドオンが用意されており、コンテナオーケストレーションの事実上の標準ツールとされています。たとえば、自動負荷分散、サービスディスカバリ、自己修復の機能により、開発者の保守や監視にかかる負担を軽減できます。さらに、マイクロサービス(植物)にもっと多くの成果が求められるようになった場合はどうでしょうか。Kubernetesは自動スケーリングとローリングアップデートをサポートし、マイクロサービスアプリケーションの安定した稼働を支えます。
注:Kubernetesの代替となるDocker SwarmやHashiCorp Nomadも、ほぼ同等の機能を提供します。

ここまで、Kubernetesを使用してマイクロサービスを管理し、アプリケーションが無秩序に増殖して制御不能になるのを防ぐ理由について説明してきました。しかし、Kubernetesとコンテナが常に必要とは限りません。アプリケーションの複雑さによっては、従来型の仮想マシン(または物理マシン)プラットフォームを選択することもできます。この場合も、自動化ツールを使用してデプロイやプロビジョニングが可能です。こうしたツールでは、Kubernetesと同等の自動化やスケーラビリティは得られませんが、比較的単純なアプリケーションや重要度の低いアプリケーションであれば、そのトレードオフを許容できる場合があります。もう1つの選択肢は、AWS Lambdaなどのサーバーレスコンピューティングプラットフォームを使用することです。これにより、基盤となるインフラストラクチャを意識することなく、イベントに応じてマイクロサービスのコードを実行できます。

園芸に詳しい人なら、コンパニオンプランツ、たとえばトマトのそばにマリーゴールドを植えることで、資源をより有効に活用し、庭をより健全に保てることを知っています。同様に、Kubernetesには幅広い機能やアドオンが用意されており、マイクロサービスの管理以外にも活用できます。たとえば、機械学習モデルやモノリスなど、マイクロサービスではないアプリにもKubernetesを使用できます。多くのお客さまがKubernetesでマイクロサービスとその他のアプリケーションを管理しており、中にはKubernetes内に仮想マシン(VM)をデプロイしているケースもあります。これは、従来のモノリシックアプリをマイクロサービス指向のアーキテクチャへ移行している組織にとって、有力な選択肢となり得ます。
問題の根本に迫る
この記事から、次の2つのポイントを持ち帰っていただければ幸いです(お近くの園芸店に行きたくなる気持ちはさておき)。
- Kubernetesにデプロイされるものが、すべてマイクロサービスとは限りません。Kubernetesが提供する機能やアドオンにより、さまざまなエコシステムで有用なツールとして活用できます。
- マイクロサービスは、必ずしもKubernetesで管理する必要はありません。アプリケーションによっては、別のツールと「ワイルドガーデン」アプローチを採用することで、より効果的に運用できます。
マイクロサービスの基礎について詳しくは、以下のリソースをご覧ください。
- ブログ – マイクロサービスアプリの構成に関するベストプラクティス
- オンデマンドウェビナー – マイクロサービスの基礎
- オンデマンドトレーニング – Microservices March 2022: Kubernetes Networking
- オンデマンドトレーニング – Microservices March 2023:マイクロサービスの提供を開始
著者について

関連するブログ記事
チュートリアル:NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介:Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト&シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux(RHEL)および関連ディストリビューションでSecurity-Enhanced Linux(SELinux)を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります