昨今の新型コロナウイルスの影響による経済的な不況により、皆さま大変ご苦労されていることかと思います。弊社でもリモートワークや時差出勤を駆使して、可能な限り業務に支障の出ない方向で取り組んでいますが、なかなか難しいものです。

従来のやり方で効率を考えると、業務体制が変わった場合に期待通りのパフォーマンスが発揮されない場合が多くあります。効率をより重視し、ソフトウェアプロダクトのリリースまでを短時間化させる概念とは何かを考えた際に重要なキーワードが DevOps（デブオプス）です。

DevOps は、ソフトウェア開発手法の一つで、開発 （Development） と運用（Operations） を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさします。 厳密な定義は存在しておらず、抽象的な概念に留まっています。
参照：Wikipedia（https://ja.wikipedia.org/wiki/DevOps）

従来の開発・運用は全く別々に管理されていましたが、両者の連携によりバグフィックスやデプロイ速度の向上が多くの実績として残っています。DevOps の環境として活用されるパターンとしては主に 2 種類あり、オンプレミスのソフトウェアとパブリッククラウドのサービスを連携させた構成をとることが多くみられます。

DevOps のプロセスは下図のようになり、製品概念からリリースまでをスムーズにおこなうためのプロセスが組まれています。

ビルドからプロダクトデプロイまでを一つのパイプラインとすることで、各ポイントでのレスポンスや対応を可能な限り迅速にできる構成を作ることが大きな目的となります。もちろん、DevOps の概念部分に書かれているとおり、厳密にルールがあるわけではありませんので、100 の DevOps があれば、100 通りの DevOps 環境が存在します。

上図はオンプレミスのソフトウェア構成になりますが、クラウドでの対応サービスは下図で代用可能となっています。その際に AWS の場合はタグ付け、Azure の場合は ARM（Azure Resource Manager）でしっかり管理しないと煩雑化する恐れがありますので要注意です。

比較図を見てもらえば気付くのですが、オンプレミスでもクラウドでも、できることはほとんど変わりません。オンプレミスですでにリソースが存在する場合は、活用することも可能かと思います。

AWS 環境での DevOps については多くの企業が活用しており、AWS 自身も活用しているためさまざまな資料がありますが、Azure 環境の文献はかなり少なく、Microsoft のページでもまだ日本語訳されていない部分が多くあります。弊社では Azure でのクラウドインテグレーションや Windows Virtual Desktop パッケージなども展開していますので、実際に Azure DevOps を無料利用枠で構築した際の注意点や、できること、できないことなどをご紹介できればと思います。

DevOps をおこなう際には、まず自分たちの開発環境や運用における課題点を洗い出す必要があります。その内容に応じて、必要なパイプラインの構成、必要なツールの選定をおこないます。

今回のテーマとしては、自社プロダクト System Answer G3 の開発環境やサポート・バージョンアップ検証などに用いられる仮想マシンの利用許可や構築を、ある程度自動化できる仕組みをテーマとします。上記の内容を実現できると、空リソース（開発環境や検証環境を物理・仮想・クラウド問わず利用できるリソースには限界値があり使っていない部分）や検証のフィードバックを迅速におこなうことが可能になるからです。

タイトルにもあるように、無料利用枠内でアーキテクチャを実現するため、あまり複雑な環境は想定せず、シンプルな構成を考えています。Microsoft のソリューションドキュメントの中に IaaS での開発環境例があったため、その内容を参考に構築をおこないました。

上図の構成では、Azure DevOps 純粋な活用方法をおこないませんでした。

Azure DevOps で基本的に活用できる手法としては、DevOps パイプラインの利用で実装可能なのですが、パイプラインを構築する上でメインとなる部分は、OS 上位のアプリケーション開発になります。各種パッケージを必要とする IaaS 環境が必要な場合は、パイプラインを用いた DevOps 環境を無料利用枠内で実装するのに時間がかかるため、Visual Studio の拡張機能を活用することにしました。もちろん DevTest Labs とパイプラインを連携させることも可能です。PaaS 環境での構築方法イメージは下図にありますが、非常に簡単に環境を作成できますので、テストアプリケーションを作成する場合などにはお勧めです。

今回は、各使用者が必要なリソース分で基本イメージをもとに自動でデプロイできる環境を目指しているため、必要分のリソース（IaaS 環境）必要者に提供が可能な Azure DevTest Labs を用いました。Azure DevTest Lab では、まず Lab を作成し、ラボ内に必要な VM を必要分デプロイします。

「1. ラボの作成」時に、Automation オプション内で事前に設定したテンプレートを使って、リソースのデプロイをおこなうことも可能です。事前に設定した場合は、Lab 自体が IaC（Infrastructure as a Code）を実現することもでき、必要に応じた環境（ラボ）を複製することもできます。

今回のアーキテクチャでは、無料利用枠なのでデフォルト状態で進めていきますが、複数の Lab 環境構築を想定する場合には、事前にコーディングすることをお勧めします。

当初の目的としては問題なく構築できたのですが、上図の構成では環境が単一のため、開発と検証でセキュアな環境とはいえませんでした。Development と Operation それぞれセキュアな環境へ変更し、下図の構成にします。構築方法に関しては、シンプル構成と同様の方法となります。検証用のラボを作成する際には VM がプール状態になりますので、後述のラボ設定を活用すると環境構築時の工数が減少します。

上記構成の場合、リソースグループを分けることで Development と Operation のそれぞれで必要な環境を確保しつつ、NW は論理的に隔離することが可能になります。

ラボ自体の運用や管理においては、ラボ画面の設定にて個人への割り当て仮想マシン数やリポジトリ管理などもおこなえるので、必須環境のインストール作業などの雑多な作業自体から解放されます。

ここでの注意点は、Azure サブスクリプションには「クォータ」の制限があります。「クォータ」は各サービスに制限があり、上限を開放する場合は Azure ポータルより引き上げ依頼をする必要がありますので、各サービスのクォータを把握する必要があります。

Azure サブスクリプションとサービスのクォータについては、以下をご参照ください。
https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/management/azure-subscription-service-limits

一通りの環境を構築した感想としては、データそのものをクラウド上に保管する必要性や、DevOps で何を効率化させるのか、社内のセキュリティポリシーとの兼ね合いなどを確認する必要がありました。弊社の場合でも、データ通信の制約上、すべてのリソースを今回の環境に構築することができませんでした。

PaaS 環境の DevOps の場合は、構成として簡単なものになります。なかなか手の出しにくい DevOps ではありますが、要件定義と構成定義に時間をかけることができれば、業務効率が向上することは間違いありません。DevOps の次世代として DevSecOps（Development & Security & Operation）も徐々に話題になっていますが、インフラ環境の定義や各種セキュリティ対策など、弊社ではさまざまなソリューションをご用意しています。現在の課題を解決する手法やソリューションをお探しの場合は、是非ともお問い合わせいただければ幸いです。

by プロダクト＆サービス統括部 SAMS サービス部 関 貴紀