0.はじめに
本記事ではサーバレス構成を例にAzureのアーキテクチャ検討のノウハウをご紹介します。
実際のPJで基盤検討メンバとして、Azureのアーキテクチャの検討に携わる機会がありましたので、ポイントだと感じた部分をピックアップして紹介します。（偏りがありますが、ご容赦ください）
こんな方にオススメ
・Azureのアーキテクチャの検討をやったことがない
・他の人がAzureアーキテクチャを検討する際の考え方を知りたい
・Azureに関する技術情報が知りたい
目次
1. 本ブログで記載するアーキテクチャ検討
アーキテクチャ検討というと、システムアーキテクチャ図を作成することをイメージする方が多いと思います。
本ブログでは、システムアーキテクチャ図を作成する前の作業として、システムの要件を実現するために、各コンポーネントをどのように構成するか検討するポイントを、基盤担当の目線でご紹介します。
2. 前提
前提は以下の通りです。
・イベント駆動型のアプリケーションを検討する
・非同期処理を検討する
・セキュリティを高める構成を検討する
3. 検討ポイント
3-1. アプリケーションのホスティング
アプリケーションのソースコードをどのコンピュートリーソースにホスティングするか、いくつか選択肢があります。
MSの公式サイトにコンピュートリソースを決定するためのディシジョンツリーがありますので、こちらを活用すると意思決定しやすいかと思います。
<引用元>Azure コンピューティング サービスを選択する
https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/compute-decision-tree
前提に記載したとおり、今回はイベント駆動としているため、Azure Fucntionsとなります。もし、アプリケーションの処理時間が長時間になることが想定される場合は、Azure App Serviceも選択肢となります。
Azure App Serviceが良い点は、制約はありますが証明書の自動更新が可能である点です。
運用をオフロードできるのはポイントが高いです。
Azure Functionsは、HTTPリクエストなどのイベント駆動型で、動くアプリケーションに最適であり、高いスケーラビリティと可用性が特徴です。
また、関数アプリを統合的に管理したい場合は、Azure API Managementを関数アプリの前段に配置する構成が考えられます。
Azure API Managementは様々な機能が利用できますが、特に関数アプリの前段で認証を行うことで、複数の関数アプリを統合的に保護できる点が有用です。
Azure API Managementを利用しない場合の選択肢として、Azure Funcionsのエンドポイントを直接公開することも可能です。その場合、以下のメリット・デメリットがあります。小規模なシステムの場合やシンプルな構成としたい場合、マッチするのではないでしょうか。
■メリット
・実装がシンプル
・コストを抑えることができる
■デメリット
・其々の関数で認証、レート制限など実装する必要がある
・統合的な管理が難しい
3-2. データベース選定
業務アプリケーションで利用するデータの格納先として、どのデータベースを選定するかについては、複雑なトランザクションを意識する必要があるかが大きな分岐点かと思います。
複雑なトランザクションが必要な場合は、リレーショナルデータベースを選定することになります。
リレーショナルデータベースの種類としては、Azure SQL Database、Azure Database for MySQL、Azure SQL Database Managed Instance等があります。詳細は、以下をご参照ください。
<留意事項>
過去にAWSの案件を担当した時に検討課題となったことがあるのですが、リレーショナルデータベースを選択した場合の注意点として、水平方向にスケールアウトするには、何らかの方法でデータをシャード化する必要があります。拡張性の要件がある場合は、判断ポイントの一つになるかと思いますので、頭の片隅に入れておくと良いかもしれません。
特にリレーショナルデータベースが必須でない場合は、業務アプリケーション次第ではありますが、拡張性に優れたNoSQLを選択することになるかと思います。
加えて、以下の点を考慮する場合、Azure CosmosDBを選択するのがよいかと思います。
・複雑なトランザクションを意識する必要がない
・アプリケーションがキーバリュー型のデータモデルに適している
・大量のトラフィックに対応可能
・自動バックアップやポイントインタイムリストアに対応可能
・大規模なリージョン障害が発生した場合にも対応可能
少し話はそれますが、最近、正式に利用可能となった動的スケーリング（リージョンごとおよびパーティションごとのオートスケール）という機能があります。特定のパーティションに負荷が集中するケースなどで、コストを削減したい場合に効果を発揮しそうです。
3-3. 非同期処理
非同期処理を組み込むことで、後続の処理がすべて完了する前にレスポンスを返すことができたり、アプリケーション間の依存関係を減らすことで、障害時の影響範囲を限定できます。
非同期処理を実現する場合は、キューイングサービスを組み込むとよいかと思います。
Azureのキューイングサービスには、Azure Queue StorageやAzure Service Busがあります。
Azure ServiceBusを選択すると、配信不能キューや順序の保証が可能であったり、リトライ処理も容易に実装できるため、アプリケーションの信頼性を高めることができます。
一方で、シンプルで低コストなキューイングサービスを利用したいのであれば、Azure Queue Storageを選択するとよいかと思います。
3-4. 複数のリージョンへのトラフィックの負荷分散
複数のリージョン間でアプリケーションのトラフィックを効率的に分散し、可用性やパフォーマンスを向上させるためには、グローバル負荷分散を構成することになるかと思います。
選択肢として、Azure Traffic ManagerとAzure Front Doorが候補にあがります。
単純にDNSのベースのルーティングを行いたい場合は、Azure Traffic Managerを選択することになります。
一方で、以下のようなケースの場合、Azure Front Doorを選択すると良いかと思います。
・WAFやDDoS保護と組み合わせて利用し、セキュリティ境界を設けたい
・URLパスベースのルーティングをさせたい
・低遅延なコンテンツ配信が求められるなど
3-5. 静的コンテンツ配信の保護
静的コンテンツ(ストレージアカウントに格納)を保護する手段として、Azure Front Door Premium + Private Linkを組み合わせて利用することができます。この方式により、ストレージアカウントをパブリックにアクセス可能にする必要がなくなり、セキュリティを高めることができます。
4. まとめ
サーバレス構成を例に主にアプリケーションに周りのAzureのアーキテクチャ検討のノウハウをご紹介しました。
実際のPJにおいては、要件によって、何を検討するか、検討の結果、どのアーキテクチャを選定するか変わってくるかと思います。一例として、本ブログでお役に立てる部分があれば幸いです。
他にもネットワーク観点や運用観点など、紹介したい内容がありますので、
続きは、どこかのタイミングで公開できればと思います。
過去のブログで、Azureのサービスプランの選定方法を紹介してます。
興味のある方は、目を通して頂けるとありがたいです。
留意事項
・2024年11月時点の情報となります。Azureサービスの仕様等、変更になる可能性がございますので、最新の情報をご確認ください。
・個人の見解であり、会社と一切関係がありません。