Windows コンテナを運用環境の Azure で動かしてきた日本でも珍しいテクの話(前編)
2019-10-21
azblob://2022/11/11/eyecatch/2019-10-21-windows-container-on-service-fabric-000.jpg

数多くの C# .Net Framework 資産

Azure をお使いの皆さんの中には、C#で開発をしている人も多いことでしょうね。そして長年作り込まれ、使い込まれたプログラムは .Net Framework で動くアプリであることも多いでしょう。

今や .Net Core も普及しつつあり、WindowsサーバーでなくともLinuxなどでもC#プログラムを動かすことができるようになりましたが、つい最近まではC#使いの選択肢はほぼ Windows に限定されていました。つまり、過去に築かれた資産の山、培った技術をそのまま活かすためには、Windows サーバーの存在が重要です。

しかし、コンテナ化やサーバーレスは世の潮流ともなっており、これまでの資産をどう活かしていくかは開発者だけでなく運用設計、アーキテクト、経営者や事業責任者の皆さんの関心事となっています。

私のチームやFIXERでは、こういった問題にも取り組んできていて、日本だけでなく世界でもなかなか珍しい、Windows コンテナをクラウド上で動かし、運用する活用技術があります。(少し自慢w)

ということで、Windows コンテナを運用環境(プロダクション環境)で実際に運用してきたノウハウを、少しご紹介したいと思います。

基本のおさらい - クラウドデザインパターン

.Net Framework は Windows上で動きます。しかしVM(IaaS)をメンテナンスしていくのは今となっては面倒で、運用性や保守性の観点からもあまり好ましくありません。では、Web Apps などのPaaS上で動かそうか、というのがこれまでの第一選択肢でした。

しかし PaaS は IaaS に比べ、モジュールのインストールなどで自由度が低い側面があり、ミドルウェアの利用などに一定の制約を受けます。例えば HULFT のようなファイル転送ミドルを使い、外部システムとデータ連携することを考えた場合、セットアップが困難です。

ファイル転送などはクラウドデザイン的ではないのでキューを使ったりBLOBで連携するなど、メッセージング処理をすることを勧める人もいるかもしれません。しかしながら、データの保証やリトライ処理、前後の処理連携などの仕組みを個別実装するのもまた「車輪の再発明」で、悩ましいところです。

とすると、例えばクラウドデザインパターンのサイドカーを発想するのですが、Web Apps などのPaaSでこれを実現するのはまた骨が折れます。

ここで、もしコンテナとコンテナオーケストレーターが使えたら、、もっと言うと Docker と Kubernetes(k8s) が使えたら、と思わない訳にはいきません。処理の中心となるアプリケーションのコンテナと、ファイル転送などの機能をセットアップしたコンテナとを1つのポッドの中にセットアップし、k8sで動かせば、非常に利便性の高い構成となります。

さらに、コンテナの最大のメリットは、イミュータブルであることだ、と私は考えています。イミュータブルであることにより、ポータビリティ(可搬性)が生まれ、これに宣言的設定のk8sと組み合わせることで、自由度の高いスケーラビリティやアベイラビリティ、そしてセルフヒーリングなども実現できているのだと捉えています。

ということで .Net Framework 資産をコンテナ化した Windows 環境で動かして、快適で安心なインフラを実現しましょう、と言うのがFIXERの最近の提案であり、実現・実践して培ってきた経験の1つです。

Windowsコンテナとは

Microsoftは仮想環境としてHyper-Vと言うテクノロジーを開発してきましたが、その培った技術と Docker とのパートナーシップにより Docker を Windows でも動くようにしています。いわゆる「Docker for Windows」ですね。手元のパソコンでインストールして試してみている方も多いかと思います。

手元で動かせているので、ではサーバーに持っていってそのまま運用できるのでは、、と素直に考えてしまうのですが、なかなか世の中はそう上手くいきません。VM(IaaS)の上で動かすことならできますが、それではVMの設計や構築、運用の手間が増えてしまいますし、vNet(仮想ネットワーク)を含めてk8sをセットアップするだけでも結構な手間です。

つまり、単体でコンテナを動かすだけならば簡単なのですが、複数のサーバーノードを使ってシステムとして汲み上げるにはかなりのハードルがあります。そして、Windows コンテナはホストOSのカーネルと、コンテナのOSのカーネルとの整合性がとても複雑というか厳密というか、繊細です。誤ってセットアップするとしばらくは動いているのに突然ハングアップするなどの障害にも見舞われます。

そういったこともあり、Azure のコンテナ対応サービスでの Windows のサポートが、まだプレビュー段階のものも多くなっています。

Windows コンテナを Service Fabric で動かす

そういう状況の中、様々な確認や試行錯誤と実験を繰り返し、Windows コンテナを Azure 上で動かすためのベストプラクティスを見つけ出しました。運用環境でも問題なく稼働するものです。

そのベストプラクティスにもいくつか種類というかパターンがあり、k8sのサービスである AKS(Azure Kubernetes Service)を使う方法や Microsoft謹製のオーケストレーターである Service Fabricを使う方法、Web Appsでコンテナを動かす方法など、必要に応じて使い分けることができます。

今回は、Azure SQL Database、Azure Cosmos DB、Cortana、Microsoft Power BI、Microsoft Intune、Azure Event Hubs、Azure IoT Hub、Dynamics 365、Skype for Business といった Azure の核となる多くのサービスで使用され多くの実績を持つ Microsoft 謹製の Service Fabric を使うパターンについてご紹介したいと思います。(後編に続く)