構築フェーズのベストプラクティス

このセクションでの推奨事項は、プロジェクトの構築フェーズを円滑に進めるのに役立ちます。構築フェーズには、コード、開発、デプロイ、実装のアクティビティが含まれ、多くの場合、設計レビューと承認セッション、そして構築内容、タイムライン、終了の基準について認識を合わせるためのキックオフミーティングで構成されています。これは、コードが記述され、ピアレビューされ、すべての AWS サービスにデプロイされるフェーズです。

以下の推奨事項では、テストや検証アクティビティも含まれます。

スタンドアップミーティングを毎日開催する

どのプロジェクト方法論を使っていたとしても、必ず毎日スタンドアップミーティングを開催してください。毎日のスタンドアップミーティングはアジャイル手法と関連していますが、ウォーターフォールモデルなど他の方法論でもチームをつなぐメカニズムとして非常に役立ちます。さまざまな方法論のベストプラクティスを取り入れたハイブリッドなプロジェクトフレームワークを使用することもできます。

考慮事項:

• Jira ボードのような軽量なものを使って、あらゆるタスクのストーリーを作成します。これらのボードは、毎日のスタンドアップミーティングのガイドになります。チームに余力と専門知識があれば、Scaled Agile Framework (SAFe) の手法を使用してエピックを作成することもできます。しかし、ほとんどのインフラストラクチャチームは、複雑なスクラムボードを管理することによる管理上のオーバーヘッドは望んでいないため、軽量なツールをお勧めします。また、ボードがあれば、チームが行う作業に関するレポートを作成でき、スコープを制御するメカニズムも得ることができます。

• グリーンフィールドの SAP プロジェクトでは、スコープがロックされた後に多くの SAP アプリケーション、または境界アプリケーションが追加されることは珍しくありません。プロジェクト範囲の制御、優先順位付け、可視化するための適切なメカニズムがなければ、プロジェクトを順調に進めるためのリソースの追加要求や作業の優先順位の変更が困難になります。

統一されたビルド仕様書を使用する

すべての環境とランドスケープに対して 1 つのビルド仕様スプレッドシートを使います。こうすることで、簡単に配置、検索できる単一のドキュメントを作成することができます。問題が発生したら簡単に復旧できるよう、バージョン管理を有効にすることをお勧めします。SAP Basis チームと協力してフォーマットを作成します。Basis チームは SAP システムに関する詳細情報を常に把握し、仕様を 1 つにまとめることで、社内のクラウドチームがプロジェクト完了後すぐにオーナーシップを取って、すべてのメタデータを 1 か所で確認できるようになります。

サーバー要件の 1 つのサンプルとして、サーバー構築の主要なメタデータを取得するのに使用するテンプレートの例を次に示します。

AWS サービスクォータに注意する

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにプロビジョニングできる仮想 CPU (vCPUs) の数にはクォータがあります。EC2 インスタンスをデプロイする場合、EC2 インスタンスのタイプによって一定数の vCPU が必要です。すべての AWS アカウントには、プロビジョニングできる vCPUsの数にソフト制限があります。EC2 インスタンスをデプロイすると、ソフト制限は約 100～150 vCPUs ずつ自動的に増加します。ただし、複数の EC2 インスタンス (例えば 20 個) を同時にデプロイしようとすると、ソフト制限を超える可能性があります。この制限にかかる可能性がある場合は、EC2 インスタンスをデプロイする前に、クォータを引き上げるリクエストを送信してください。デプロイの途中で Service Quotas の制限に達するのを防ぐことができます。

セキュリティのためのキーローテーション戦略を策定する

AWS Key Management Service （AWS KMS) を使用すると、お客様は暗号化キーを簡単に作成および管理し、さまざまな AWS サービスやさまざまなアプリケーションでの使用を制御できます。SAP 実装では、 AWS KMS キーは Amazon Elastic Block Store (Amazon EBS) ボリュームに保存され、SAP バイナリと SAP HANA ファイルシステムに使用される保管中のデータを暗号化するために使用されます。KMS キーは、ソフトウェアメディアとバックアップを保持するために Amazon Simple Storage Service (Amazon S3) バケットに保存されているデータ、および /usr/sap/transと 用の Amazon Elastic File System (Amazon EFS) ファイルシステムに保存されているデータにも使用されます/sapmnt。 AWS KMS を使用すると、 AWS マネージドキーまたはカスタマーマネージドキーのいずれかを柔軟に使用できます。構築フェーズの開始時に、セキュリティキーの管理戦略と決定事項を文書化して共有することをお勧めします。カスタマーマネージドキーから AWS マネージドキーへの切り替えなど、プロジェクトの途中でセキュリティポリシーを変更する場合は、SAP 環境を完全に再構築する必要があり、プロジェクトのタイムラインに影響を与える可能性があります。

キーの使用とローテーションについて、すべてのセキュリティ関係者から同意を得てください。クラウドまたはオンプレミス環境向けの既存のキーローテーションポリシーを検討し、 AWSで使用できるようにこれらのポリシーを変更します。キー管理の戦略についてコンセンサスを得ることが難しい場合は、意思決定者にセキュリティのベースラインとレベル設定に関する考慮事項を理解してもらうためのトレーニングを実施してください。環境を構築する前に、キーローテーションに関する決定を下すことが重要です。例えば、カスタマーマネージドキーから AWS マネージドキーに変更する場合、Amazon EBS で問題が発生し、暗号化キーをオンラインで変更することはできません。EBS ボリュームは、新しいキーを使って再構築しなければなりません。そのため、SAP インスタンスを再構築する必要がありますが、これは理想的なシナリオではありません。

同様に、プロジェクトが Vormetric などの外部キー管理ソリューションを使用していて、キーマテリアルを にインポートする場合は AWS KMS、セキュリティの意思決定者が外部 KMS キーと AWS KMS キー間のキーローテーションの違い (自動ローテーション) を認識していることを確認してください。セキュリティポリシーに従って外部 KMS キーを使用し、ローテーションすると、キーマテリアルだけでなく、キーの Amazon リソースネーム (ARN) も変更されます。つまり、EBS ボリュームを再作成する必要があり、SAP システム全体を小規模に移行させる必要があります。一方、 でカスタマーマネージドキーまたは AWS マネージドキーの自動ローテーションを有効にすると AWS KMS、キーマテリアルは変更されますが、キー ARN は変わりません。つまり、EBS ボリュームは影響を受けません。キーローテーションの詳細については、 AWS KMS ドキュメントの「キーのローテーション AWS KMS」を参照してください。

もう 1 つのセキュリティアプローチは、データベースとオペレーティングシステムのパスワードローテーション AWS Secrets Manager に を使用することです。これは、標準ダッシュボードから利用できます。さらに、悪意のあるアクティビティから環境を保護するために、ディザスタリカバリ環境の AWS Identity and Access Management (IAM) ロールが本番環境から分離されていることを確認します。

未使用サーバーの廃止

有用性がなくなった直後に概念実証 (PoC) サーバーを廃止することをお勧めします。使用していないサーバーを稼働させると、コストがかかる可能性があります。グリーンフィールドの SAP 実装のために構築したすべてのサーバーを把握し、構築フェーズであまり使用されていないサーバーは停止して廃止することが重要です。サーバーを廃止する前に、EC2 インスタンスの Amazon マシンイメージ (AMI) バックアップを作成することができます。そうすることで、今後まったく同じサーバーを起動する必要が生じた場合に、バックアップを復元することができます。

サーバーの廃止は、実装プロジェクトの終了まで先延ばしにするべきではありません。プロジェクトの全期間と、実装完了後のメンテナンスフェーズまたは運用フェーズにおいても、使用されていないサーバーの使用状況を監視し、停止し、最終的には破棄する必要があります。料金はすぐに蓄積されるため、SAP Basis チームメンバーにこれらのサーバーの廃止を教えるプロセスを最初に設定してください。