0. はじめに
MS社様主催のAzureの提案トレーニングとなるものに参加してきました。せっかくなので、トレーニングの内容と検討したアーキテクチャをご紹介したいと思います。
こんな方にオススメ
・オンプレからAzure(PaaS)へ移行する場合のアーキテクチャを知りたい方
・要件からどのようなAzureサービスを選定するか知りたい方
・Azureに関する技術情報を収集したい方
・今後、Azureのシステムの提案を予定している方
1. 提案トレーニング参加の動機
提案トレーニング参加の動機は以下です。
・Azureの実際のPJを経験して学んだことの再現性を確認する
・要件からアーキテクチャの検討を行う経験をしてみたかった
・他者の考え方を学び、吸収する
2. 提案トレーニング内容
提案トレーニングの内容は、オンプレのシステムからAzureへ移行を考えているお客様に対し、提示された要望やヒアリングをインプットに、移行後のAzureのシステム構成と見積もりを提案する２日間の研修でした。
進め方としては、各グループでアーキテクチャの検討を行い、そこで出てきた疑問点などをお客様へヒアリング。さらに検討した上で、社内レビューを受けてフィードバックをもらい、最終的にお客様へ、Azureのシステムの提案を行うものでした。
大まかな流れは以下の通りです。
1日目：移行後のシステム構成の検討とお客様へヒアリング、社内レビュー。
↓
各グループで提案資料準備。(1週間でアーキテクチャ構成図と料金計算ツールで見積りを作成）
↓
2日目：お客様に対して提案内容を説明。QAやフィードバックを受けて、再検討して、全体で共有。
3. トレーニング参加で得られたもの
・要件から方式を検討するプロセスを体験できた。
(普段の業務では、大まかなアーキテクチャが決まっているところからのスタートなので新鮮だった）
・他者の意見を聞くことで、知識の幅や考え方の視野が広がった。
・知識不足の部分が明らかになり、今後の学習のきっかけになった。
・オンプレからのリフト/シフト案件での、アーキテクチャ検討のノウハウが得られた。
・検討のプロセスは、他のCSP(クラウド ソリューション プロバイダ)でも転用できると感じた。
・今回は使えなかったが、要件を網羅的に摺合せられる、非機能グレードは便利だと感じた。
4. アーキテクチャの検討内容の紹介
要件の文章を汲み取って、どのようなAzureサービスを検討したか、簡易的ではありますが、ご紹介できればと思います。その前に、検討する上で重要だと思ったポイントに触れてみたいと思います。それは、クラウドへ移行する目的と前提条件を関係者全員で共通認識を持った上で検討することです。
今回のケースの場合は、目的は、運用に掛るSE費用を含めたコストを削減すること。前提条件は、アプリケーションの改修を最小限に抑えたい、PaaSを利用による軽微な改修は許容される等が明示されていました。
(明示されていない場合は、こちらからお客様と握りにいく動きが必要かもしれません。)
仮に目的と前提条件を外してしまうと、お客様に響かない提案となり、受注が危ぶまれます。また、受注してシステム移行ができたとしても、移行自体が目的化してしまい、移行はできたが、目的は達成できていないといった結果になり、次に案件に繋がりにくくなるかと思います。
それでは、以降で各要件に対する検討内容を簡潔にご紹介します。(順不同）
4-1. アプリケーションは.NETで実装
アプリケーションを動かすAzureのコンピューティングサービスについて、プログラム言語やバージョンに対応しているか確認する。(記載するほどでもないかもですが。)
4-2. 仮想サーバを利用
IaaSかPaaSを選定する。運用をオフロードしたい、ソフトウェア固有の要件がなければ、PaaS(App ServiceやFunctions)を選択。改修を最小限に抑え、まずはクラウドに乗せることが優先事項であれば、Azure VMを選択する。但し、VMでそのまま移行した後、PaaSへの再移行する必要になった場合、ハードルが高いと想定される。
また、仮想ネットワークやバックアップ、監視の設計がVMとPaaSで異なる点は、注意しておきたい。
4-3. Webサーバなどを外部公開している
インターネットの入口として、Application GatewayかFront Doorが選択肢となる。(両者を併用することも可能。)
マルチリージョンに対応する要件やCDNとして、海外からのアクセスに対するレイテンシーを考慮するのであれば、Front Door。それ以外は基本、Application Gateway。
4-4. ネットワークをDMZと内部セグメントに分割している
VNetやサブネットでNWを分割する。
基本的には、ペアリングの転送コストやNWのレイテンシの観点から、サブネットを分割し、NSGによる制御で十分と考えられる。
但し、部署が別など明確に分割する要件があれば、VNetで分けることも選択肢となる。もしくは、部署ごとのコストを明確化にするには、タグの適用可否も検討するとよい。
4-5. DBのクラスターを利用している
基本的には、データベースサービスのPaaSを選択する。
対応しているデータベース製品のPaaSがない場合は、IaaSを選択する。
SQL DatabaseのPaaSを利用する場合、エラスティックプールなどを活用し、データベースを分割しつつ、リソースを有効活用する仕組みなどがある。こういった仕組みを提案要素に組み込むのもよい。
4-6.インターネットに公開するため、セキュリティを十分に考慮した構成としたい
Azureで提供されているセキュリティサービスや機能を利用する。
DDoS保護、WAF、アクセス制御、セキュリティ監視、シークレット管理など。
以下にAzureで利用できるセキュリティサービスが分かりやすく纏まっているため、参照するとよい。
4-7. 機会損失を防止するため、可用性を十分にとりたい
SLAやゾーン冗長に対応しているサービス、プランを利用する。
留意点としては、Azureは基本、３つの可用性ゾーンとなる。そのため、構成図で表現する場合や見積もりの際は、2つではなく、３つである点、注意が必要。
4-8. 監視やバックアップもクラウドサービスを利用したい
バックアップは、Azure Backup、監視はAzure Monitor。
但し、バックアップ機能はデータベースやストレージのサービスに備わっているものもあるため、それで賄えるか確認し、そうでない場合は、バックアップ専用のサービス(Azure Backup）や仕組みを検討するとよい。
余談だが、Azure SQL Databaseについては、長期保管として最大10年間バックアップを保持できる模様。
4-9. アプリケーション更新のダウンタイムを抑えたい
アプリケーションのデプロイについて、スロットなどを活用して、ダウンタイムを局所化できるブルー／グリーンデプロイなどを検討するとよい。
4-10. Webサイトで問い合わせの自動化したい
基本、RAGを活用する。但し、FAQレベルの回答で十分であり、コストを可能な限り抑えたい場合は、簡易なチャットボットとして、Azure Languageを活用できる可能性がある。(詳細に確認できていないため、実現性の確認が必要）
4-11. Webサイトの訪問状況を分析できるようにしたい
Application Insightを活用するとよい。但し、要件に記載してある内容や要望が満たせるかは検討が必要。
5. 参考_システム構成図
実際にトレーニングで作成したアーキテクチャ図を参考までに載せておきます。
6. まとめ
簡単ではありますが、Azure提案のトレーニングの内容の少し考察などを加えて、ご紹介しました。実際に議論や発表を通して、フィードバックを受けることで、アウトプットだけでなく、インプットの場としても有益と感じました。今後もこのような機会を活用して、引き出しを増やしていければと思います。
最後までお読みいただきありがとうございました。
留意事項
・2025年5月時点の情報となります。Azureサービスの仕様等、変更になる可能性がございますので、最新の情報をご確認ください。
・個人の見解であり、会社と一切関係がありません。