アプリケーション開発およびインフラストラクチャ管理の合理化のためにアプリケーション プラットフォームを改良する

  • [アーティクル]

組織のプラットフォーム エンジニアリング プラクティスを改善する上で重要なのは、アプリケーション プラットフォームを評価することです。 アプリケーション プラットフォームには、組織内の開発、デプロイ、アプリケーション管理をサポートするために使用されるすべてのツールとサービスが含まれています。

簡素化と標準化

コードとしてのインフラストラクチャ (IaC) と自動化ツールをテンプレートと組み合わせて、インフラストラクチャとアプリケーションのを標準化できます。 エンド ユーザーのプラットフォーム固有の負担を軽減するために、プラットフォームの詳細を関連する名前付け規則に分類し、抽象化します。次にその例を示します。

  • リソースの種類のカテゴリ (高コンピューティング、高メモリ)
  • リソース サイズのカテゴリ (T シャツのサイズ変更、小、中、大)

テンプレートは、事前設定された構成でテストされた一般的な要件を表すを必要があります。そのため、開発チームはすぐに最小限のパラメーターの指定を開始でき、オプションを確認する必要はありません。 ただし、公開されたテンプレートで、利用可能なオプションや望ましいオプションよりも多くのオプションをチームが変更する必要がある場合があります。 たとえば、承認されたデザインでは、サポートされているテンプレートの既定値以外の特定の構成が必要な場合があります。 このインスタンス運用チームまたはプラットフォーム エンジニアリング チームは、1 回限りの構成を作成し、テンプレートにこれらの変更を既定として組み込む必要があるかどうかを決定できます。

ドリフトを自動的に修復できるドリフト検出機能を備えた IaC ツール (GitOps) を使用して変更を追跡できます。 これらのツールの例としては、Teraform クラウド ネイティブ IaC ツール (例: Cluster API、Crossplane、Azure Service Operator v2) があります。 IaC ツールのドリフト検出の外部には、リソース構成のクエリを実行できるクラウド構成ツール (Azure Resource Graph など) があります。 これらは 2 つの利点として機能します。インフラストラクチャ コードの外部で変更を監視し、変更されたプリセット構成を確認します。 厳しくなりすぎないように、事前に定義された制限を使用して、デプロイにも許容範囲を実装できます。 たとえば、Azure Policy を使用して、デプロイに含めることができる Kubernetes ノードの数を制限できます。

自己管理または管理

パブリック クラウドでは、SaaS、PaaS、または IaaS を使用できます。 SaaS、PaaS、IaaS の詳細については、トレーニング モジュール「クラウドの概念を説明する」をご覧ください。 PaaS サービスは、合理化された開発エクスペリエンスを提供しますが、アプリ モデルに関してはより規範的です。 最終的には、使いやすさと制御の間にあるトレードオフを評価する必要があります。

プラットフォームの設計時に、組織のサービス ニーズを評価し、優先順位を付けます。 たとえば、 Azure Kubernetes Service (AKS) または Azure Container Apps (ACA) を使用してアプリを直接構築するかどうかは、サービスの要件と社内の容量とスキル セットによって異なります。 Azure Functions または Azure App Service などの関数スタイルのサービスも同様です。 ACA、Azure Functions、App Service は複雑さを軽減しますが、AKS では柔軟性と制御性が向上します。 OSS RADIUS インキュベーション プロジェクトのような実験的性格の強いアプリ モデルでは、2 つの間のバランスを取ろうとしますが、一般に、完全なサポートと確立された IaC 形式でのプレゼンスを備えたクラウド サービスと比較すると、成熟度においてより初期の段階にあります。

計画時に特定した問題は、このスケールのどちらの端が自分に適切しているかを評価するのに役立ちます。 決定を下す際には、必ず独自の既存内部スキル セットを考慮に入れる必要があります。

共有リソースと専用リソース

組織内には、稼働率とコスト効率を向上させるために複数のアプリケーションで共有できるリソースがあります。 各共有リソースには、独自の考慮事項群があります。 たとえば、K8s クラスターを共有するための考慮事項は次のとおりですが、他の種類のリソースに適用されるものもあります。

  • 組織: クラスターなどのリソースを、組織の境界を越えてではなく、組織の境界内で共有することで、組織の方向性、要件、優先順位に合わせる方法を改善できます。
  • アプリケーション テナント: アプリケーションは、異なるテナント分離要件を持つことができます。他のアプリケーションと共存できるかどうか、個々のアプリケーションのセキュリティと規制のコンプライアンスを確認する必要があります。 たとえば、Kubernetes では、アプリケーションで名前空間の分離を使用できます。 ただし、さまざまな環境の種類のアプリケーション テナントも検討する必要があります。 たとえば、構成ミスやセキュリティの問題による予期しない影響を回避するために、テスト アプリケーションと同じクラスター上の実稼働アプリケーションを混在させないようにすることが最善の場合がよくあります。 または、共有クラスターにデプロイする前に、まず専用の Kubernetes クラスターをテストしてチューニングして、これらの問題を追跡することもできます。 それでも、混乱や間違いを避けるためには、アプローチの一貫性が鍵となります。
  • リソース消費量: 各アプリケーション リソースの使用状況、予備の容量を理解し、予測を実行して共有が実行可能かどうかを見積もります。 また、消費されるリソースの制限 (データ センターの容量またはサブスクリプションの制限) にも注意する必要があります。 目標は、共有環境でのリソースの制約のためにアプリケーションと依存関係を移動したり、容量が不足したときにライブ サイト インシデントを発生させたりしないようにすることです。リソースの制限、代表的なテスト、監視アラート、レポートを使用して、リソース消費量を特定し、リソースを消費しすぎるアプリケーションから保護します。
  • 共有構成の最適化: 共有クラスターなどの共有リソースには、追加の考慮事項と構成が必要です。 これらの考慮事項には、クロス 課金、リソース割り当て、アクセス許可の管理、ワークロードの所有権、データ共有、アップグレードの調整、ワークロードの配置、ベースライン構成の確立、管理、反復、容量の管理、ワークロードの配置が含まれます。 共有リソースには利点がありますが、標準構成が制限的すぎて進化しない場合は、時代遅れになってしまいます。

ガバナンス戦略を実装する

ガバナンスはガードレールを使用してセルフサービスを有効にするための重要な要素ですが、アプリケーションのビジネス価値実現までの時間に影響を与えない方法でコンプライアンス ルールを適用することは、よくある課題です。 ガバナンスには、次の 2 つの部分があります。

  • 初期展開コンプライアンス (適切な開始): カタログを通じて使用できる標準化された IaC テンプレートを使用して実現できます。許可されたリソースと構成のみをデプロイできるようにするためのアクセス許可の管理とポリシーを使用します。
  • コンプライアンスの維持 (適切な状態を維持): ポリシー ベースのツールを使用すると、リソースの変更が発生した際、ユーザーに対して制止または警告できます。 コア インフラストラクチャ以外にも、K8s などのリソース内のコンプライアンスと、コンテナーまたは VM で使用される OS をサポートするツールも検討してください。 たとえば、ロックダウンされた OS 構成を適用したり、Windows グループ ポリシー、SELinux、AppArmor、Azure Policy、Kyverno などのセキュリティ ソフトウェア ツールをインストールしたりできます。 開発者が IaC リポジトリにのみアクセスできる場合は、承認ワークフローを追加して、提案された変更を確認し、リソース制御プレーン (Azure など) への直接アクセスを防ぐことができます。

コンプライアンスを維持するには、問題にアクセスし、報告し、対処するためのツールが必要です。 たとえば、Azure Policy は、監査、報告、修復のために多くの Azure サービスで使用できます。 また、ニーズに応じて、Audit、Deny、DeployIfNotExists などの異なるモードもあります。

ポリシーはコンプライアンスを適用できますが、アプリケーションが予期せず中断される可能性もあります。 そのため、大規模に運用する場合は、コードとしてのポリシー (PaC) への移行を検討してください。 PaC は、適切に開始し、適切な状態を維持するアプローチの重要な要素として次の機能を提供します。

  • 一元管理の標準
  • ポリシー用のバージョン コントロール
  • 自動化テストと検証
  • ロール アウトにかかる時間の短縮
  • 継続的なデプロイ

PaC は、次のような機能を備えた不適切なポリシーの影響範囲を最小限に抑えるのに役立ちます。

  • レビューおよび承認されたリポジトリにコードとして格納されるポリシー定義。
  • テストと検証を提供する自動化。
  • 既存のリソースに対するポリシーと修復のリングベースの段階的なロールアウトは、潜在的に不適切なポリシーの影響範囲を最小限に抑えるのに役立ちます。
  • 修復タスクには安全性が組み込まれており、デプロイの 90% を超えるデプロイが失敗した場合に修復タスクを停止するなどの制御があります。

ロール固有の監視とログ記録を実装する

アプリケーションとインフラストラクチャをサポートするには、スタック全体の監視とログ記録が必要です。

監視とログ記録を示す Grafana ダッシュボードの図。

要件はロールごとに異なります。 たとえば、プラットフォーム エンジニアリングおよび運用チームには、適切なアラートを使用してインフラストラクチャの正常性と容量を確認するためのダッシュボードが必要です。 開発者は、アプリケーションとインフラストラクチャの正常性を示すダッシュボードのトラブルシューティングとカスタマイズを行うために、アプリケーション メトリック、ログ、トレースを必要とします。 これらのロールのいずれかが経験する可能性のある問題の 1 つは、情報過多による認知的過負荷、または有用な情報の不足による知識のギャップです。

これらの課題を解決するには、次の点を考慮してください。

  • 標準: 標準化されたダッシュボードの作成と再利用を容易にし、OpenTelemetry 監視フレームワークなどを使用してインジェスト処理を簡略化するために、ログ記録標準を適用します。
  • アクセス許可: Grafana などを使用してチームレベルまたはアプリケーション レベルのダッシュボードを提供し、関心のあるユーザーにロールアップ データを提供し、アプリケーション チームの信頼できるメンバーが必要に応じてログに安全にアクセスできるようにする機能を提供します。
  • 保持: ログとメトリックの保持にはコストがかかる場合があり、意図しないリスクやコンプライアンス違反が発生する可能性があります。 保持の既定値を確立し、適切な開始のガイダンスの一部として公開します。
  • リソースの制限を監視する: 運用チームは、特定の種類のリソースの制限を特定して追跡できる必要があります。 これらの制限は、Azure Policy などのツールを使用して IaC テンプレートまたはポリシーに組み込む必要があります。 その後、操作では、Grafana などのダッシュボードを使用して事前に監視し、自動スケーリングが不可能または有効になっていない共有リソースを拡張する必要があります。 たとえば、時間の経過と同時にアプリがオンボードおよび変更されるため、容量の K8s クラスター ノードの数を監視します。 アラートが必要であり、これらの定義は、プログラムによってリソースに追加できるようにコードとして格納する必要があります。
  • 主要な容量と正常性メトリックを特定する: Prometheus や Azure Container Insights などのメトリック収集を使用して、OS と共有リソース (例: CPU、メモリ、ストレージ) の不足を監視し、警告を発します。 使用中のソケット/ポート、おしゃべりなアプリのネットワーク帯域幅の消費量、クラスターでホストされているステートフル アプリケーションの数を監視できます。

最小限の特権、統合されたセキュリティ管理、脅威検出の原則を使用してセキュリティを構築する

セキュリティは、コード、コンテナー、クラスター、クラウド/インフラストラクチャのすべてのレイヤーで必要です。 推奨される最低限のセキュリティ手順を次に示します。

  • 最小限の特権の原則に従います。
  • 複数のパイプラインにわたって DevOps セキュリティ管理を統合します。
  • コンテキストに基づく分析情報を確認して、最も重大なリスクを特定して修復します。
  • 実行時にクラウド ワークロード全体の最新の脅威に対する検出と対応を有効にします。

この領域の問題を解決するには、クラウドとハイブリッド (たとえば、Microsoft Defender for Cloud) にまたがるエンジニアリングおよびアプリケーション システム、リソース、サービス全体で動作するツールを評価するツールが必要です。 アプリケーションのセキュリティ以外に、次の点を評価します。

アクセス許可の要件は、環境によって異なる場合があります。 たとえば、組織によっては、個々のチームが実稼働リソースにアクセスすることは許可されておらず、レビューが完了するまで新しいアプリケーションを自動的にデプロイすることはできません。 ただし、自動化されたリソースとアプリのデプロイと、トラブルシューティングのためのクラスターへのアクセスは、開発環境とテスト環境で許可する必要があります。

サービス、アプリケーション、インフラストラクチャへの ID アクセスを大規模に管理することは困難な場合があります。 ID 情報を作成、維持、管理するための ID プロバイダー。 プランには、アプリケーションとサービスの認証サービスが含まれている必要があり、ロールベースのアクセス制御承認 (RBAC) システムと大規模に統合できます。 たとえば、Microsoft Entra ID を使用すると、Azure Kubernetes Service などの Azure サービスに対して認証と承認を大規模に提供できます。個々のクラスターに直接アクセス許可を設定する必要はありません。

アプリケーションでは、ストレージなどのクラウド リソースにアクセスするために ID へのアクセスが必要になる場合があります。 要件を確認し、ID プロバイダーが可能な限り最も安全な方法でこれをサポートする方法を評価する必要があります。 たとえば、AKS 内では、クラウド ネイティブ アプリは、Microsoft Entra ID とフェデレーションするワークロード ID を利用して、コンテナー化されたワークロードの認証を許可できます。 このアプローチにより、アプリケーションは、アプリケーション コード内でシークレット交換なしでクラウド リソースにアクセスできます。

ワークロード所有者を特定し、リソースを追跡して、コストを削減する

コスト管理は、プラットフォーム エンジニアリングのもう 1 つの要素です。 アプリケーション プラットフォームを適切に管理するには、ワークロード所有者を識別する方法が必要です。 特定のメタデータ セットの所有者にマップされるリソースのインベントリを取得する方法が必要です。 たとえば、Azure 内では、AKS Labels、Azure Resource Manager タグを使用して、あるいは Azure Deploy Environments などの概念を使用して、リソースをさまざまなレベルでグループ化できます。 これを機能させるには、ワークロードとリソースをデプロイするときに、選択したメタデータに必須のプロパティ (Azure Policy などを使用) が含まれている必要があります。 これは、コストの割り当て、ソリューション リソース マッピング、所有者に役立ちます。 孤立したリソースを追跡するには、定期的なレポートを実行することを検討してください。

追跡を超えて、Microsoft Cost Management などのコスト管理システムで、この同じメタデータを使用して、個々のアプリケーション チームにリソース使用量のコストを割り当てる必要がある場合があります。 この方法では、アプリケーション チームによってプロビジョニングされたリソースを追跡しますが、ID プロバイダー、ログとメトリック ストレージ、ネットワーク帯域幅消費量などの共有リソースのコストはカバーされません。 共有リソースの場合、運用コストを個々のチームで均等に分割したり、一様でない消費がある専用システム (ログ ストレージなど) を提供したりできます。 一部の共有リソースの種類では、リソースの使用量に関する分析情報を提供できる場合があります。たとえば、Kubernetes には OpenCost や Kubecost などのツールがあり、役立ちます。

また、現在の支出を確認できるコスト分析ツールも探す必要があります。 たとえば、Azure portal には、グループ内のリソースの使用量を追跡し、事前設定されたしきい値に達したときに通知を送信できるコストアラートと予算アラートがあります。

投資するタイミングと場所を決定する

複数のアプリケーション プラットフォームがある場合、高コストや可観測性の低下などの問題を解決する改善に投資するタイミングと場所を決定するのは難しい場合があります。 新たに開始する場合、Azure アーキテクチャ センターには、評価できる可能性のあるパターンがいくつかあります。 それ以外に、何をしたいかを計画する際に考慮すべきいくつかの質問を次に示します。

質問 ヒント
既存のアプリケーション プラットフォームを適応させますか。それとも新たに開始しますか。あるいは、これらのアプローチを組み合わせて使用しますか。 今あるものに満足している、または新たに開始している場合でも、時間の経過と共に適応し、変化する方法を考える必要があります。 即時の変更が機能することはめったにありません。 アプリケーション プラットフォームは移動するターゲットです。 理想的なシステムは時間が経つにつれて変わります。 この考え方と関連する移行計画を今後の設計に組み込む必要があります。
現在の作業を変更する場合、どの製品、サービス、または投資に満足していますか。 「壊れていないものは直すな」という言葉があります。理由なく変更しないでください。 ただし、自社開発のソリューションがある場合は、長期的なメンテナンスを節約するために既存の製品に移行するかどうかを検討してください。 たとえば、独自の監視ソリューションを運用している場合、運用チームからその負担を取り除き、新しいマネージド製品に移行しますか。
時間の経過と共に最も変化が起きているのはどこですか。 これらは、組織アプリの種類のすべて (またはほとんどすべて) に共通する領域にありますか。 お客様や社内の顧客が満足していないものの、頻繁に変更する可能性が高くない領域は、出発点として最適な場所です。 これらは長期的に見て最も大きな投資収益率をもたらします。 これは、新しいソリューションへの移行を容易にする方法を見つけるのにも役立ちます。 たとえば、アプリ モデルは流動的である傾向がある一方で、ログ分析ツールは寿命が長くなる傾向があります。 また、方向転換によって期待通りの成果が得られるかを確認しながら、開始する新しいプロジェクトやアプリケーションに焦点を当てることもできます。
付加価値が最も高い領域でカスタム ソリューションに投資していますか。 独自のアプリ インフラストラクチャ プラットフォーム機能が競争上の優位性の一部であることを強く感じていますか。 ギャップを特定した場合は、カスタムを行う前に、ベンダーが最も投資する可能性が高い領域を検討し、カスタムの考え方を他の場所に集中させます。 まず、カスタム アプリ インフラストラクチャやアプリ モデル プロバイダーではなく、インテグレーターとして考えることから始めます。 構築したものはすべて維持管理する必要があり、長期的には初期費用をはるかに上回る額になります。 ベンダーによって長期的にカバーされると思われる領域でソリューションをカスタムビルドする緊急の必要性を感じる場合は、サポート終了または長期サポートを計画してください。 通常、社内の顧客は、カスタム製品と同じくらい (それ以上ではないにしても) 既製の製品に満足します。

既存のアプリケーション プラットフォームへの投資を適応させることが、良いスタートとなる場合があります。 更新を行う場合は、新しいアプリケーションから始めて、あらゆる種類のロールアウトの前に、アイデアのパイロットの簡略化を検討してください。IaC とアプリケーション テンプレートによるこの変更の要因。 影響の大きい、価値の高い領域で、独自のニーズに合わせてカスタム ソリューションに投資します。 それ以外の場合は、既製のソリューションを使用してみてください。 エンジニアリング システムと同様に、時間の経過と共に変化を管理するのに役立つ 1 つの厳格なパスを想定するのではなく、プロビジョニング、追跡、デプロイの自動化に重点を置きます。

関連するコンテンツ

開発者のセルフサービス基盤を設計する