アプリケーション プラットフォームを調整する

  • [アーティクル]

プラットフォーム エンジニアリングの 取り組みで最初に取り組みたい問題を理解したら、アプリケーション プラットフォームでいくつかの課題に対処する必要がある場合があります。 この記事では、その方法に関するいくつかのヒントを提供します。 よく設計されたアプリケーション プラットフォームを作成する際に見逃されたり、忘れられたりする側面について詳しく学習します。 具体的には、インフラストラクチャ管理、セキュリティ、コスト管理、ガバナンス、監視。

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

現在 1 つ以上のアプリケーション プラットフォームがある場合は、特定した問題を解決する改善に投資するタイミングと場所を決定するのは難しい場合があります。 新しく開始する場合、 Azure アーキテクチャ センター には、評価するための潜在的なパターンがいくつかあります。 しかし、それ以外に、何をしたいかを計画し始める際に考慮すべきいくつかの質問を次に示します。

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

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

設計とアーキテクチャに関する考慮事項

使用できる可能性のあるアプリケーション プラットフォーム パターンがいくつかありますが、重要ですが、設計時に見逃されることが多い一般的な領域を次に示します。

インフラストラクチャ管理

「ソフトウェア エンジニアリング システムの適用」で説明したように、IaC と自動化ツールをテンプレートと組み合わせて、インフラストラクチャとアプリケーションの展開を標準化できます。 エンド ユーザーのプラットフォーム固有の負荷を軽減するには、次のように、選択肢を関連する名前付け規則に分割して、プラットフォームの詳細を抽象化する必要があります。

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

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

ドリフト (GitOps) を自動的に修復できるドリフト検出機能を備えた IaC ツールを使用して変更を追跡できます。 これらのツールの例としては、 Terraform ツールとクラウド ネイティブ 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 クラスターを最初にテストして調整して、これらの問題を追跡することもできます。 関係なく、混乱や間違いを回避するには、アプローチの一貫性が重要です。
  • リソースの消費量: 各アプリケーション リソースの使用状況、予備の容量を理解し、共有が実行可能かどうかを見積もるプロジェクションを行います。 また、使用されるリソースの制限 (データ センターの容量またはサブスクリプションの制限) にも注意する必要があります。 目標は、共有環境でのリソースの制約によるアプリケーションと依存関係の移動を回避するか、容量不足によるライブ サイト インシデントを発生させることです。 リソース制限、代表的なテスト、監視アラート、レポートを使用すると、リソースの消費量を特定し、他のアプリケーションに影響を与える可能性のあるリソースが多すぎるアプリケーションから保護できます。
  • 共有構成を最適化する: 共有クラスターなどの共有リソースには、追加の考慮事項と構成が必要です。 これらの考慮事項には、クロスチャージ、リソース割り当て、アクセス許可管理、ワークロード所有権、データ共有、アップグレード調整、ワークロード配置、ベースライン構成、容量管理、ワークロード配置の確立、管理、反復が含まれます。 共有リソースには利点がありますが、標準構成の制限が厳しすぎて進化しない場合は、古くなります。

これらの問題の一部は PaaS ソリューションによって簡略化されていますが、これらの点の多くは、データベースの共有のようなものにも当てはまります。 共有にはアップサイドとダウンサイドの両方があるため、トレードオフを慎重に検討する必要があります。

この記事の Kubernetes クラスターの側面の詳細については、Azure Kubernetes Service (AKS) マルチテナントのドキュメントを参照してください。

ガバナンス

ガバナンスは、ガードレールを使用してセルフサービスを有効にするための重要な部分ですが、アプリケーションのビジネス価値に時間を影響しない方法でコンプライアンス 規則を適用することは一般的な課題です。 ガバナンスは広範なトピックですが、これが発生している問題である場合は、この領域の両方の側面に留意してください。

  • 初期展開コンプライアンス (開始右): これは、許可されたリソースと構成のみをデプロイできるようにするためのアクセス許可の管理とポリシーを使用して、カタログを通じて使用できる標準化された IaC テンプレートを使用して実現できます。
  • コンプライアンスの維持 (適切な状態を維持): ポリシー ベースのツールを使用すると、リソースの変更が発生したときにアラートを生成したり防ぐことができます。 コア インフラストラクチャ以外に、K8s などのリソース内のコンプライアンスと、コンテナーまたは 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 などのダッシュボードを使用して事前に監視し、自動スケーリングが不可能または有効になっていない共有リソースを拡張する必要があります。 たとえば、時間の経過と同時にアプリがオンボードおよび変更されるため、K8s クラスター ノードの数で容量を監視します。 アラートは必要であり、これらの定義はプログラムによってリソースに追加できるようにコードとして格納する必要があります。
  • 主要な容量と正常性メトリックを特定する:Prometheus や Azure Container Insights などを使用して、OS と共有リソース (CPU、メモリ、ストレージなど) を監視してアラートを生成し、メトリックコレクションを使用して枯渇を確認します。 使用中のソケット/ポート、チャットアプリのネットワーク帯域幅消費量、クラスターでホストされているステートフル アプリケーションの数を監視できます。

Security

コード、コンテナー、クラスター、クラウド/インフラストラクチャなど、すべてのレイヤーでセキュリティが必要です。 すべてのorganizationには独自のセキュリティ要件がありますが、大まかに言えば、プラットフォームで考慮すべき点がいくつかあります。

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

この領域の問題を解決するには、クラウドとハイブリッド (クラウドのMicrosoft Defenderなど) にわたってエンジニアリングとアプリケーションのシステム、リソース、サービス全体で機能するツールを評価するツールが必要です。 アプリケーションのセキュリティを超えて、次の評価を行う必要があります。

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

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

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

メタデータ & コスト管理

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

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

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

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