次の方法で共有

開発とインフラストラクチャの管理を効率化するためにアプリケーション プラットフォームを調整する

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

簡素化と標準化

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

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

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

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

自己管理型または他者管理型?

パブリック クラウドでは、サービスとしてのソフトウェア (Saas)、サービスとしてのプラットフォーム (PaaS)、またはサービスとしてのインフラストラクチャ (IaaS) を使用することができます。 SaaS、PaaS、IaaS の詳細については、トレーニング モジュール「 クラウド サービスの種類について説明する」を参照してください。 PaaS サービスは、合理化された開発エクスペリエンスを提供しますが、アプリ モデルの方が規範的です。 最終的には、評価する必要がある使いやすさと制御の間にトレードオフがあります。

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

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

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

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

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

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

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

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

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

ポリシーはコンプライアンスを適用できますが、アプリケーションが予期せず中断される可能性もあります。 そのため、大規模に運用する場合は、コードとしてのポリシー (PaC) プラクティスに進化することを検討してください。 PaC は、スタートの正しいアプローチと適切なアプローチを維持するための重要な部分として、次の機能を提供します。

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

PaC は、次のような機能を使用して、不適切なポリシーの爆発半径を最小限に抑えるのに役立ちます。

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

ロール固有の可観測性とログ記録を実装する

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

可観測性とログ記録を示す Grafana ダッシュボードのスクリーンショット。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連コンテンツ

  • Last updated on