Azureで新サービスを試してみるときに、現役のクラウドエンジニアが意識している7つの観点　#Azureリレー | cloud.config Tech Blog

FIXERの藤井です。先週の弊社の松枝の「診断ログは怖くない！欲しいログを探すコツ #Azure リレー」に引き続き、毎週水曜日Azure リレー第24回を担当します。

初めに

クラウドでは日々新しいサービスがリリースされているため、追われるように新サービスを試し続けることが、「クラウドエンジニア」と呼ばれる職業の宿命です。そもそもクラウド自体が広大で、全ての機能を試した状態に到達することは永遠になく、比較的歴史の長いサービスであっても、クラウドエンジニア個人にとっては、業務上の必要が発生したときに初めて触ってみるということが、頻繁にあります。
本記事ではおそらく最もポピュラーの2つのサービス「Azure App Service」と「Azure SQL Database（Azure SQL Server）」を例として、「藤井が新サービスを試すときに観ているポイント」をご紹介します。

観点（1）必須の関連サービスが存在するか否か

Azure Portalの「Market Place」より、構築したいサービスを検索して構築します。ウイザードの指示に従って進んで最後までいけば、基本的に構築はできます。必須の関連サービスが存在する場合、Azure Portalから作成する中で「新規で同時に作成する or 既存のものを利用する」を選択を求められます。
下図の例ではAzure SQL Databaseの作成時に、Azure SQL Serverについて新規で作成するか、既存のものを利用するかの選択をしています。

観点（2）バックアップ系の機能や設定を確認してみる

どんなAzureのサービスであるにせよ、業務で利用する場合、「バックアップ」の設定は必ず考慮が必要となる「命綱」とでも言うべき要素です。あまり考えにくいシチュエーションですが、もし新しく試しているサービスについて、「バックアップ」系の機能が提供されていなかったら、自分でバッチ処理を組むかあるいは「バックアップを取らなくても良い理由を確認する」かのいずれかの対応が必要となります。下図はApp ServiceとSQL Databaseそれぞれのバックアップ設定の画面です。

観点（3）ログ系の機能や設定を試してみる

Azureの各サービスに共通して「診断ログ」機能および、サービスごとに様々なログ出力機能が提供されています。ログを常日頃から出力して閲覧できるようにしておかないと、万が一の障害時に原因究明も根本解決も全くできず、文字通り「お手上げ」の状態になるため、ログの利用方法は確認しておきます。下図の例はApp Serviceのログの設定画面と閲覧画面です。

観点（4）セキュリティ系の機能や設定を試してみる

社会の一部では「クラウドなら安心安全」とか「クラウド事業者（AzureにおけるMicrosoft）が責任をもってセキュリティを守ってくれる」というイメージがありますが、それはあくまで「標準として提供されているセキュリティ系の機能を一通り適切に設定していること」が前提です。新サービスを試すときは、セキュリティ系の機能や設定は一通り確認しておきます。
下図はSQL Database のセキュリティ設定の画面の例です。

観点（5）メトリック系の機能や設定を試してみる

クラウドの各種サービスは「従量課金」という性質上、メモリサイズやCPUコア数といった利用するリソースについて、適正な水準を確認することが不要なコストを節約するために必要不可欠です。「メトリック」としてサービスごとにリソースの利用状態を監視することで、過不足の有無を確認します。
逆にリソース不足によるシステムの不安定化も回避するという目的もあります。
利用するサービスについて「メトリック」としてどんな項目が取れるかを確認する必要があります。
下図はApp ServiceとSQL Databaseそれぞれのメトリックとして取得される項目の例です。

観点（6）複数サービスを組み合わせを試してみる

ほとんどのAzureサービスは単独で利用されるものではなく、他のサービスと組み合わせて利用します。例えば「フロントエンド:App Service/データ保存領域:SQL Database」という組み合わせです。
【参考】「拙記事：AZ-203 : Developing Solutions for Microsoft Azure の合格に向けた学習のポイント」より「( 4 ) データ保存領域への読み書き」にて、Azure KeyVaultを利用した、「App Service / SQL Database」のセキュアな接続を解説しています。

観点（7）上記（1）～（6）についてコマンドラインツールを使った作業を試してみる

観点（1）~（6）まではAzure Portalを使った操作を前提にしていますが、最後の仕上げは実業務での作業を想定し、コマンドラインツールを利用して同様の作業ができることを確認します。
Azure Portalでは感覚的に作業ができてしまうことの弊害として、理解が甘い状態に気が付かずにいるリスクがあります。仕組みや構造についてより厳密に理解するためや、実業務での様々な要求に応えるためにコマンドラインツールで作業できることを担保します。
Azure で利用できるコマンドラインツールは以下の二つがあります。

Azure PowerShell：PowerShellベースでWindows ユーザー向け
Azure CLI：PythonベースでMac OS / Linuxユーザー向け

Azure PowerShellについては以下の拙記事でも解説しています。併せてご参照ください。

終わりに

本記事の7つの各観点は必ずしもAzureだけに固有とは限らず、AWSやGCPでも同様と考えられます。もし将来、藤井が業務上の必要でAWSやGCPに取り組むことがあったとしても、まずは本記事の（1）~（7）の観点に従うことになると予想しています。