チームがコストを考慮した設計を行えるようにする - 基盤の構築:コスト最適化のための環境設定

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

チームがコストを考慮した設計を行えるようにする

コスト最適化は、Well-Architected Framework の柱です。コスト最適化により、デベロッパーとエンジニアリングチームが事後、つまり早期の意思決定段階で環境に組み込まれた問題に対処するにはもう手遅れで経済的でない時点になってから、ワークロードを最適化しなければならないという事態を避けることができます。

コストを考慮した設計を行えるチームは、短時間でイテレーションを行い、時間とともに学習できるため、ベストプラクティスが日々のオペレーションに組み込まれるようになります。次のプラクティスは、チームのコスト設計に役立ちます。

  • 可視化を図り、ツールを使用することで、一貫性のあるレポート、測定、アカウンタビリティを促進し、透明性を高める。

  • 適切なアクションが取られた際にポジティブなインセンティブを生み出すことで、適切な行動を促す (最適化の成功を紹介する、経営陣からのメールなど)。

  • 俊敏性を維持しながら統制ポリシーを確立する (例: 大き過ぎるリソースを特定して対応するプロセスを用意したり、非本番稼働用リソースに対しては勤務時間外にオフにするオプトアウトポリシーを設けたりするなど)。

次に、コスト最適化を推進するうえで役立つアイデアをいくつか取り上げます。

  • インセンティブ – メトリクスの視覚化とゲーミフィケーションや、結果に基づいたリーダーシップからの積極的なコミュニケーションが含まれます。効率性と経済性が重視されることをチームに理解してもらい、意思決定がコストに与える影響をデベロッパーやエンジニアが考慮できるように手助けします。また、非効率性を回避する方法も提供します。

  • ユーザーに対するコストのチャージバック – チャージバックは、ビジネスユーザーが IT の効率性を重視するインセンティブを生み出します。その結果、IT はコストセンターとしてではなく、企業が使用し、企業によって支払われるリソースとして扱われます。

  • プロセスにおける障壁の排除 – デベロッパーやエンジニアが行う最適化を妨げる障壁がある場合があります。たとえば、環境に対する変更事項は、すべて変更レビュープロセスを通す必要があるというポリシーが設定されている場合があります。これにより、適切なサイジングと伸縮性を推進する取り組みが妨げられます。このようなポリシーを修正することで、最適化の取り組みを合理化できます。

  • アジャイルな作業方法 – 設計のイテレーションサイクルにコストがメトリクスとして含まれる場合、組織において同等またはそれ以上の成果を低コストで実現する能力が時間とともに向上します。

  • トレーニングとオンボーディング – 個人は通常、使い慣れたツールやテクニックを活用して問題を解決します。これは、効率を最大化するための最新のプラクティスを取り入れたトレーニングとオンボーディングを通じて対応できます (サーバーレスアーキテクチャの使用、Amazon CloudFront の使用によるコンピューティング需要の削減など)。

次のアプローチも効果的ですが、注意して実施しないと、俊敏性を損なうリスクがあります。

  • 経営陣のサポートやプレッシャー – ベストプラクティスに対するサポートは、スタッフの満足度にプラスの影響を与えるため、コストプレッシャーよりも優先されます。コストプレッシャーは、非効率性を隠すインセンティブを生み出し、予算のロックダウンをはじめ、俊敏性とイノベーション能力の喪失につながる可能性があります。

  • アーキテクチャレビュー – 通常、アーキテクチャレビューの非実施 (または任意のレビュー) と必須レビューとの間に、妥当なバランスの取れるポイントがあります。過剰な必須レビューはボトルネックになる可能性があります。結果による影響が大きく、コストも高いプロジェクトでは、各組織が定義した境界でのレビューが必要になる場合があります。

  • オーケストレーション管理 – プロジェクトとリソースの承認ワークフローでは、財務と予算を保護するために、俊敏性とイノベーションがリスクにさらされます。管理と俊敏性のバランスを取る方法の 1 つは、収益創出サービスに対するコスト管理を少なくする (または行わない) ことです。これらのサービスに高度なメトリクスを設定することで、このような問題を相殺できます。