BicepによるAzure Resourceのデプロイ
エーピーコミュニケーションズ ACS事業部亀崎です。 今回は私がずっと追い続けているBicepの共通モジュール化の取り組みについてご紹介します。
Bicepは宣言型の構文を使用してAzureリソースをデプロイするドメイン固有言語（DSL）です。BicepがAzコマンドに組み込まれたのが2021年3月、Az CLI (v2.20) のことでした。 その頃から本ブログでBicepの使用方法等についてご紹介してきました。
そして、Bicepモジュールによる再利用も当時からご紹介してきています。
実は、この頃から私自身は再利用部分のモジュールをまさに「再利用」し続けてきました。
Bicepモジュール再利用の実際
2021年春依頼、検証用も含めていくつかのシステムのAzure ResourceのデプロイでBicepを利用してきました。 その際の基本的なファイル構成は以下のようなものです。「共通bicepモジュール」と記載している部分が2021年以降再利用し続けている部分です。
例えばWebアプリケーションのシステムを考えた場合、実装言語やデータベースの種類などは異なるかもしれませんが、実は基本的なシステム構成はそれほど変わりません。このため、「だいたい前回システムAで使った構成で、一部パラメータだけ変更してシステムBで使おう」とか「システムAではAKS使ったけど、システムBではそれをAzure Container Appsにしよう」とか、それぞれのシステム固有部分で決めるべき部分と、共通化して利用できる部分に分離することができるのです。
もちろん、Bicepや各種Azure Resourceも進化します。新しいサービスにも対応していかなければなりません。そうした場合は共通モジュール部分に追加・更新をしてきました。
しかし、こうした更新は共通モジュール化せずにシステムごとにIaCファイルを定義、利用した場合にも発生します。それを1箇所で更新していけばいいのですから、共通モジュール化の利点は大きいのではないかと感じています。
また、あらたなシステムを追加する場合でも、これまで問題なく稼働しているIaCファイルを再利用できるのですから、IaCを新規に作成する場合に比べて時間も短縮できますし、なにより安心感があります。
こうした共通モジュール化を複数の組織間で進めるのがPlatform Engineeringであり、共通モジュール化は関心事の分離でもあると私は考えて言います。
Platform TeamがAzure Resourceのプロビジョニング方法をまとめ、ベストプラクティスやガバナンス上必要な項目を事前に組み込むなどテンプレートを整備し、各チーム（Stream-aligned Team）に提供する。各Stream-alignedチームはAzure Resourceの難しいところはあまり意識することなく（認知負荷が低い状態で）実際にプロビジョニングができるようなる（機能開発に集中する）。Platform TeamはよりよいPlatformはどういったものかにフォーカスしてさらなる改善・追加を行い、適宜バージョンアップしていく。
これこそが、IaC領域・分野でのPlatform Engineeringではないでしょうか。
今回、約2年のBicep共通モジュールの利用を通じて、あらためてIaCとPlatform Engineeringについて考えてみました。 共通モジュール化もまだまだ足りない部分があると考えています。今後は、Bicep ModuleのPrivate registry機能を使って、バージョニングもより簡単に実現できるようにしたいと思います。
さらに、その変更点などを如何にStream-aligned Teamに伝えるか、共通モジュールを見つけてもらうか、利用方法をどのように伝えていくか、どのようにセルフサービス化するかについても検討を進めていきたいと考えています。（このあたりは Backstage の得意分野ではないかと考えています。）
さらに進化した共通モジュール化、Platform Engineeringの成果をまたご紹介するべく努力し続けたいと思います。
最後に
弊社ではクラウドネイティブ分野のシステム導入・開発支援を行っています。IaCやPlatform Engineeringなどもこれらのサービスの一部でもあります。ご興味のある方はぜひご連絡ください。
