【Microsoft Azure】サイドカーパターンアーキテクチャをお手軽実装しよう on App Service

こんにちは、MS開発部の渋谷です。

先日Azure App ServiceのLinuxプランにて、サイドカーの拡張機能が使えるようになりました。 Introducing Sidecar Extensions for Azure App Service on Linux – Azure App Service

今回はサイドカーパターンのメリットとAzure App Serviceでサイドカーパターンのアプリをホストする方法について解説します。

 

サイドカーパターンとは？

サイドカー パターンとは、アプリケーション本体とは別のプロセスやコンテナーに補助的な機能を分けて配置する方法です。たとえば、アプリケーション自体にはユーザー向けの主要な処理だけを担当させ、監視、ログ記録、設定管理、ネットワークサービスなどの補助機能はサイドカーと呼ばれる別プロセスで行います。

サイドカーパターンのポイント

互いに分離されている

• 補助機能を、アプリケーション本体と別のプロセスやコンテナーで動かすので、一方に問題が起きてももう一方に影響しにくくなります。

異なる技術や言語を使える

• メインのアプリケーションが特定のプログラミング言語で作られていても、サイドカーの機能は別の言語や技術で実装できます。
• そのため、各担当チームが自分たちにとって開発しやすい環境を選ぶことができます。

近くに配置されているので通信が速い

• サイドカーは常にメインアプリと同じホスト（サーバー）やコンテナー内に配置されるため、連携する際の待ち時間が少なくなります。

ライフサイクル（起動・停止）が一緒

• メインのアプリケーションと一緒にサイドカーも作成され、終了します。つまり、アプリが動いている間は、サイドカーも一緒に動いています。

サイドカーパターンの使いどころ

アプリケーションを作るとき、しばしば「監視・ログ管理・設定の保存」など、いろいろな補助作業が必要になります。これらの作業をメインのアプリに直接組み込んでしまうと、もし一つの機能でエラーが起きたときに、全体に影響を及ぼす恐れがあります。

そこで、補助の機能だけを別のプロセス（もしくはコンテナー）に分け、メインと「添える」形にすることで、次のようなメリットが得られます。

• アプリケーションの品質や安定性が向上する
• 異なる技術を柔軟に使える
• 個々の機能を別々に管理・更新しやすい

そのため、次のような場合にはサイドカーパターンアーキテクチャを検討してみるとよいでしょう。

• アプリケーションが複数の言語やフレームワークで作られているとき
• 補助機能を他のチームや組織で管理したいとき
• メインと同じサーバーで補助機能を実行したいとき
• アプリ全体のライフサイクルを共有しながら、部分的に独立して更新したいとき
• 特定の機能に対して、メモリ使用量などのリソース制限を個別に行いたいとき

一方で、次のような場合はサイドカーパターンがあまり適切ではない状況だと考えられます。

• メインと補助機能間での通信に極めて低い待ち時間が求められる場合（通信オーバーヘッドが問題になる場合）
• 小規模なアプリケーションで、リソースの分離によるメリットよりもデプロイの手間が重くなる場合
• メインアプリとは別に独立してスケールさせたい場合は、そもそも別サービスとして作ったほうが良いことがある

Azure App Serviceでサイドカーパターンを利用してみる

Azure App Serviceでサイドカーを利用するためには作成時に設定をする必要があります。

AzureポータルでApp Serviceを作成する場合は、Webアプリ作成の「コンテナ」タブにて「サイドカーのサポート」をオンにしてください。

BicepやARMテンプレートでサイドカーを有効にしたApp Serviceを作成する場合は、「linuxFxVersion」の設定を「sitecontainers」にしてください。
（参考：appservice-linux-sidecar/nginx-sample/armtemplatemultictr.json at main · Azure-Samples/appservice-linux-sidecar）

 

サイドカーサポートが有効になると、App Serviceのポータル画面にあるデプロイセンターからサイドカーのコンテナを追加することが可能となります。

   

実際のサイドカーの追加画面は以下のようになります。

   

サブスクリプションとAzure Container Registryを設定しサイドカーとして利用するコンテナのイメージとタグを選択するだけで追加可能です。また、ARMテンプレートやBicepの場合でも同様にコンテナを追加することが可能です。この場合、サイドカーではないコンテナには「isMain」を「true」に、サイドカーには「isMain」を「false」に設定することに注意してください。

（参考：appservice-linux-sidecar/nginx-sample/armtemplatemultictr.json at main · Azure-Samples/appservice-linux-sidecar）

App Serviceのサイドカー機能の注意点

サイドカーコンテナでは、メイン コンテナーと同じネットワーク ホストが共有されます。実際には、コンテナ間の通信は「localhost:<port>」を使用して通信可能です。そのため、メインコンテナとサイドカーコンテナでは同じポート番号を利用することはできません。

また、サイドカーのログとメインコンテナのログは、現状標準のApp Serviceログに混ざって出力されます。

さらに、App Serviceのサイドカーでは、すべてのコンテナのライフサイクルは同じという、サイドカーパターンに乗っ取った実装をしているため、コンテナ個別のスケーリングや再起動はサポートしていません。ちなみに、環境変数やボリューム、VNET統合は通常のApp Serviceと同様に利用可能です。

 

まとめ

この記事ではサイドカーパターンの解説やApp Serviceでのサイドカー機能の利用方法について解説しました。

Azure App Serviceはすでに安定したサービスになってきましたが、最新の機能がどんどん入ってきているので、その技術選定の参考になれば幸いです。