国の行政機関においては以下ガイドも参照すること。

• 「国の行政機関向けシステムのリソース最適化の実施についてopen_in_newOpens in new tab」

本手順では、EC2インスタンスにおける推奨改善事項の確認方法を例示する。

他のサービスにおける推奨事項の確認方法の詳細は以下のAWS公式ドキュメントを参照すること。

• リソースのレコメンデーションの表示
  https://docs.aws.amazon.com/ja_jp/compute-optimizer/latest/ug/viewing-recommendations.htmlopen_in_newOpens in new tab

1-1.AWSマネジメントコンソールへのログイン

対象システムが稼動するAWSアカウントにログインする。

なお、Switchロールから、後述の操作に必要な権限を持ったユーザー（ロール）にスイッチして作業すること。

必要な権限は以下のAWS公式ドキュメントを参照すること。

• Compute Optimizerへのアクセス
  https://docs.aws.amazon.com/ja_jp/compute-optimizer/latest/ug/security-iam.htmlopen_in_newOpens in new tab

1-2.Compute Optimizerの有効化

サービス一覧から「AWS Compute Optimizer」を選択する。

Compute Optimizer画面への遷移後、Compute Optimizerの利用開始画面が表示される場合は本手順を実施すること。

表示されない場合は、本手順は実施不要とし次の手順1-3.推奨事項の確認を実施する。

図 13 AWS Compute Optimizer有効化

「ご利用開始」を押下後、「オプトイン」を押下する。

なお、オプトインの実施後、Compute Optimizerにて推奨事項が表示されるまでに最大24時間かかる点に留意すること。

図 14 AWS Compute Optimizerオプトイン

1-3.推奨事項の確認

EC2リソース最適化に向けた推奨事項を確認する。

EC2のメモリ使用率を用いた過剰なプロビジョニング状態の確認が必要な場合は、EC2CloudWatchエージェントをインストールし、定義ファイルの設定を行うこと。

必要に応じて、AWS公式ドキュメントを参照し、CloudWatchエージェントのインストールおよび設定を行うこと。

実施後、推奨事項の分析が完了するまでに最大24時間かかる点に留意すること。

Compute Optimizer画面のダッシュボードのリージョン欄にて、「すべてクリア」を押下し、全てのリージョンを対象にする。

図 15 AWS Compute Optimizerダッシュボード

Compute Optimizer画面のダッシュボードの「リソースの最適化オプション」欄にてAmazon EC2の「最適化されていない」インスタンスまたは「アイドル」インスタンスが存在するかどうかを確認する。

Amazon EC2に「最適化されていない」インスタンスと「アイドル」インスタンスが共に存在しない場合は、手順1-6.推奨事項一覧のエクスポートから実施すること。

「最適化されていない」インスタンスが存在する場合は、「リソースタイプ」列の「EC2 インスタンス」を押下し、手順1-4.コスト削減内容の確認（「最適化されていない」インスタンス）を実施すること。

「アイドル」インスタンスが存在する場合は、「アイドル」列を押下し、手順1-5.コスト削減内容の確認（「アイドル」インスタンス）を実施すること。

1-4.コスト削減内容の確認（「最適化されていない」インスタンス）

Compute OptimizerのEC2インスタンスに関するレコメンデーション画面にて、「CPU アーキテクチャの詳細設定」を押下し、「現在」のみにチェックを入れる。

図 16 AWS Compute Optimizer CPUアーキテクチャの詳細設定

「結果=過剰なプロビジョニング」でフィルタする。

図 17 AWS Compute Optimizer 「過剰なプロビジョニング」によるフィルタ

「推定月間節約額 (オンデマンド)」列記載のコスト削減額、および「推奨インスタンスタイプ」列記載のインスタンスタイプを確認する。

各推奨事項に対する詳細なアクションは「インスタンスID」を押下することで確認できる。

図 18 AWS Compute Optimizer 推定月間節約額と推奨インスタンスタイプ

本確認を、表示されているインスタンス分実施する。

なお、本確認は手順1-6-1.推奨事項のエクスポートにてエクスポートしたEC2推奨事項一覧を用いて実施することもできる。

1-5.コスト削減内容の確認（「アイドル」インスタンス）

「リソースタイプ=EC2 インスタンス」でフィルタする。

「推定月間節約額 (オンデマンド)」列記載のコスト削減額を確認する。

各推奨事項に対する詳細なアクションは「リソースID」を押下することで確認できる。

図 19 AWS Compute Optimizer アイドル状態のリソースの推定月間節約額

1-6.推奨事項一覧のエクスポート

1-6-1.推奨事項のエクスポート

以下のAWS公式ドキュメントを参照し、エクスポート先のS3バケットを作成する。

• レコメンデーションのエクスポートに使用する既存の S3 バケットの指定
  https://docs.aws.amazon.com/ja_jp/compute-optimizer/latest/ug/create-s3-bucket-policy-for-compute-optimizer.htmlopen_in_newOpens in new tab

左ペインの「レコメンデーション」欄記載の「ライツサイジング」内にある「EC2 インスタンス」を押下し、フィルターが設定されていないことを確認の上、「エクスポート」を押下する。

図 20 AWS Compute Optimizer 推奨事項のエクスポートの留意点

• 「レコメンデーションをエクスポート」画面にて以下の設定し、推奨事項一覧をエクスポートする。
  • 「エクスポート先と名前付け」欄にて、S3バケットを指定する。「オブジェクトプレフィックス」の指定は任意とする。
  • 「フィルタをエクスポート」欄にて、「CPU アーキテクチャの詳細設定」の項目が「現在」のみとなっていることを確認する。
  • 「含める列」欄にて、「すべて選択」を押下し、全ての項目にチェックが入っていることを確認する。
  • 画面下部の「エクスポート」を押下し、推奨事項一覧をエクスポートする。

図 21 AWS Compute Optimizer 推奨事項のエクスポート

S3バケットにエクスポートした推奨事項一覧をダウンロードする。

Compute Optimizerにてエクスポートした推奨事項一覧をもとに、CloudWatchを用いて各リソースが稼働していない時間帯を過去のメトリクスから確認する。

※Compute Optimizerを用いてCPU使用率、ネットワークI/O等のメトリクスを参照することは可能だが、最大14日分のメトリクスしか確認できないため、CloudWatchにて1か月程度のメトリクスを確認すること。

本手順では、EC2インスタンスにおけるリソースの利用状況を確認する手順を例示する。

他のサービスにおけるリソース利用状況の確認方法の詳細は以下のAWS公式ドキュメントを参照すること。

• CloudWatch メトリクスを発行する AWS のサービス
  https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.htmlopen_in_newOpens in new tab

なお、後述の操作に必要な権限を持ったユーザー（ロール）でコンソールにログインして作業すること。

必要な権限は以下のAWS公式ドキュメントを参照すること。

• CloudWatchへのアクセス
  https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.htmlopen_in_newOpens in new tab

1.利用時間帯の特定

対象インスタンスのリソース状況を確認する。

サービス一覧から「CloudWatch」を選択する。

「すべてのメトリクス」画面の「参照」タブにて、対象インスタンスの「リソースID」で検索を実施し、任意のメトリクスにチェックボックスを入れる。

• 確認メトリクス例：
  • CPUUtilization（CPU使用率）
  • NetworkIn/NetworkOut（ネットワークI/O）
  • メモリ使用率　※対象インスタンスへCloudWatch Agentの導入が必要

メトリクスを過去４週間以上で表示し、曜日・時間帯ごとのパターンを確認する。

※「グラフ化したメトリクス」タブにて、集計の粒度を変更できる。曜日単位の確認では1時間、時間帯の確認では5分とする等、パターンごとに集計粒度を変更すること。

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2.インスタンスタイプの変更

「＜共通＞Compute Optimizerによる推奨改善事項確認」で確認した推奨事項をもとに、対象のEC2インスタンスに対して推奨のインスタンスタイプへの変更を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

変更手順の詳細は以下のAWS公式ドキュメントを参照すること。

• Amazon EC2 インスタンスタイプの変更
  https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-resize.htmlopen_in_newOpens in new tab

3.リソースの削除

「＜共通＞Compute Optimizerによる推奨改善事項確認」で確認した推奨事項をもとに、対象のEC2インスタンスに対してリソースの停止・削除を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

稼働時間をスケジューリングすることで過剰リソースが解消される場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2.スケジュール停止の実装

「＜共通＞Compute Optimizerによる推奨改善事項確認」で確認したリソース状況をもとに、該当するリソースの稼働時間や要件を見直し、曜日・時間帯でのスケジュール停止の運用や必要に応じて停止・起動の自動化を検討する。

スケジュール停止・起動の実装にあたっては、EventBridge Scheduler等のスケジューリングサービスの利用を検討すること。

EventBridge Schedulerのサービス詳細は以下のAWS公式ドキュメントを参照すること。

• Amazon EventBridge スケジューラのセットアップ
  https://docs.aws.amazon.com/ja_jp/scheduler/latest/UserGuide/setting-up.htmlopen_in_newOpens in new tab

なお、インスタンス起動時に、稀に一時的なキャパシティ不足のエラーによりインスタンス起動が失敗する可能性があるため、起動のリトライの処理を含めた自動化を行う等の対応をあわせて検討すること。また、スケジュールによる停止起動の対象とするインスタンスについては、コスト削減効果と上記エラー等による起動失敗時の業務影響度を総合的に勘案の上、決定すること。

キャパシティ不足のエラーを踏まえた停止・起動の運用の考え方については、今後GCASガイド上で提供予定のため、そちらを参照されたい。

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2. ボリュームの最適化

2-1. タイプ/IOPSの変更

「最適化されていない」ボリュームで確認した推奨内容をもとに、ボリュームタイプやIOPSが最適化の候補となる場合は動的なボリュームの変更を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

• EBSボリュームの変更
  https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/requesting-ebs-volume-modifications.html#modify-ebs-volumeopen_in_newOpens in new tab

2-2. サイズダウン

「最適化されていない」ボリュームで確認した推奨内容をもとに、EBS容量が過剰な場合は小容量ボリュームへの付け替えを検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

EBSは直接の容量縮小が不可能なため、対象ボリュームのスナップショット作成→リソースダウン済みの新ボリューム作成→旧ボリュームからの切り替え→不要となったボリュームとスナップショットの削除の手順で対応すること。

各手順は、以下のAWS公式ドキュメントを参照すること。

• スナップショットの作成
  https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-creating-snapshot.htmlopen_in_newOpens in new tab
• スナップショットからボリュームを作成
  https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-creating-volume.htmlopen_in_newOpens in new tab
• EBSボリュームのアタッチ
  https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-attaching-volume.htmlopen_in_newOpens in new tab
• EBSボリュームのデタッチ
  https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-detaching-volume.htmlopen_in_newOpens in new tab

2-3. リソースの削除

「アイドル」ボリュームで確認した推奨内容をもとに、孤立したスナップショットや未使用EBSが確認された場合は、削除を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

EBSボリュームの削除においては、スナップショットの作成を事前に実施することが推奨されている。削除手順に関しては、AWS公式ドキュメントを参照すること。

• Amazon EBS ボリュームの削除
  https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-deleting-volume.htmlopen_in_newOpens in new tab

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2.リソースの削除

確認したリソース状況をもとに、定常的に利用が確認できないインスタンスは削除候補として検討する。

削除前に一定期間インスタンスを停止し、業務影響を確認することを推奨する。インスタンスを停止している間、インスタンス使用料は課金されない。

稼働時間をスケジューリングすることで不要なリソースを最適化可能な場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

1.ログ情報の収集

1-1.ログサービスの設定情報の確認

取得しているログサービスの保存場所や保持期間等の現状を確認する。

※基本的にログの保存場所はS3かCloudWatch Logs、またはその両方となっている。

• 主要なログサービス
  • Cloud Watch Logs
  • S3サーバーアクセスログ
  • ELBサーバーアクセスログ
  • Cloud Trail
  • VPC Flow Logs
  • AWS Config　等

保存場所がCloudWatch Logsの場合は、保持期間設定を確認し、S3の場合はライフサイクルルール設定を確認する。

確認場所は以下のAWS公式ドキュメントを参照すること。

• CloudWatch Logs ログの保持期間
  https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SttingLogRetentionopen_in_newOpens in new tab
• S3 オブジェクトライフサイクルの管理
  https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/object-lifecycle-mgmt.htmlopen_in_newOpens in new tab

1-2.ログの利用要件の確認

各ログに関して、業務における利用状況や規定等の要件を確認する。

• 確認事項の例
  • 規制や法令に基づくセキュリティ要件や保持義務の有無
  • アラートや可視化等の運用・監視用途での利用有無
  • セキュリティ監査やコンプライアンスチェックでの利用有無

2.コスト削減可否の検討

手順1.ログ情報の収集（AWS）の確認情報をもとに、各ログに対して利用期間、保持すべき期間、アーカイブへの移行タイミング等ルールの見直しを検討する。

見直した要件を元として以下の設定を検討する。

3.ログの保管方法の変更

3-1.保持期間設定の変更 - CloudWatch Logs

手順1.ログ情報の収集（AWS）の確認情報をもとに、各ログに対する保持期間設定の要件を検討し、以下の手順に従って設定の変更を実施する。

CloudWatch Logsの場合、ログの保持期間はデフォルトで「無制限」となっているため、保持期間設定の変更実施を推奨する。

なお、後述の操作に必要な権限を持ったユーザー（ロール）でコンソールにログインして作業すること。

必要な権限は以下のAWS公式ドキュメントを参照すること。

• CloudWatchへのアクセス
  https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.htmlopen_in_newOpens in new tab

サービス一覧から「CloudWatch」を選択する。 「ロググループ」画面にて、対象のロググループにチェックを入れ、「アクション」＞「保持設定を編集」を押下する。

要件に定めた保持期間を設定し、「保存」することで、設定期間を超過したログを保持しないことととする。

※長期保持する場合、CloudWatch LogsはS3よりコストがかかるため、リアルタイム監視を実施していない、もしくはリアルタイム監視を実施する期間を超えたログをS3へ転送する運用も検討すること。

検討にあたっては以下のAWS公式ドキュメントを参照すること。

• サブスクリプションを使用したログデータのリアルタイム処理 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/Subscriptions.htmlopen_in_newOpens in new tab

3-2.ライフサイクルルール設定の変更 - S3

手順1.ログ情報の収集（AWS）の確認情報をもとに、各ログに対するライフサイクルルール設定の要件を検討し、以下の手順に従って設定の変更を実施する。

サービス一覧から「Amazon S3」を選択する。「バケット」画面にて対象のバケットを選択し、「管理」タブにて「ライフサイクルルールを作成する」を押下する。

ライフサイクルルール名を入力し、ライフサイクルルールを適用する範囲であるルールスコープを設定する。

• 特定のプレフィックスやタグを持つオブジェクトにライフサイクルルールを適用するには「1つ以上のフィルターを使用してこのルールのスコープを制限する」を選択し、「プレフィックス」もしくは「タグの追加」を設定する。
• バケット内のすべてのオブジェクトにライフサイクルルールを適応するには「バケット内のすべてのオブジェクトに適用」を選択する。

要件に定めたライフサイクルルールを選択し、「ルールの作成」をすることで、設定期間を超過したログを他のストレージクラスに移行、もしくは削除すること。

オブジェクトを他のストレージクラスに移行するルール設定を実施する場合は、以下のAWS公式ドキュメントを参考にし、適切なクラスへの移行を検討すること。

• Amazon S3 ライフサイクルを使用したオブジェクトの移行
  https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html#how-to-set-lifecycle-configurationopen_in_newOpens in new tab

補助的ストレージサービス（S3、EFS等）に対して、利用容量、アクセス頻度、リクエスト数等を可視化し、最適化余地を特定する。

以下は、最も利用が多いと推測されるS3での見直し手順を記載しているが、他のストレージサービスにおいても本手順を汎化して見直しを実施すること。

1.ストレージ利用情報の収集

1-1.バケットの利用状況の確認 ‐ S3 Storage Lens

S3 Storage Lensを用いて、S3バケットがベストプラクティスに基づいて設定されているかを確認する。

サービス一覧から「Amazon S3」を選択する。「Storage Lens」の「ダッシュボード」画面から「ダッシュボードを作成」を押下する。

以下を設定し、「ダッシュボードを作成」する。

※ダッシュボードは作成後48時間後に表示される。

• 任意のダッシュボード名を入力
• ステータス「有効にする」を選択
• 任意のメトリクスを選択　※「高度なメトリクスとレコメンデーション」を利用すると、「無料のメトリクス」では14日間だったメトリクス範囲が15カ月まで拡張でき、追加のメトリクスも集計可能となる。有料オプションであるため、以下のAWS公式ドキュメントを参照し、適宜利用を検討すること。
  • Amazon S3 ストレージレンズを理解する https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_metrics_selectionopen_in_newOpens in new tab

ダッシュボードが有効化されたら、対象のダッシュボードを選択し、以下を確認する。

• 7 日以上経過した未完了のマルチパートアップロードを含むバケット
• 多数の旧バージョンが蓄積されているバケット
• 未完了のマルチパートアップロードを中止するためのライフサイクルルールが設定されていないバケット
• 旧バージョンのオブジェクトを期限切れにするライフサイクルルールがないバケット
• オブジェクトを別のストレージクラスに移行するためのライフサイクルルールがないバケット

確認にあたっての詳細は、以下のAWS公式ドキュメントを参照すること。

• Amazon S3 ストレージレンズを使用したストレージコストの最適化
  https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/storage-lens-optimize-storage.htmlopen_in_newOpens in new tab

1-2.バケット内オブジェクトの利用要件の確認

各バケット、オブジェクトに関して、業務における利用状況や規定等の要件を確認する。

• 確認事項の例
  • 規制や法令に基づくセキュリティ要件や保持義務の有無
  • アラートや可視化等の運用・監視用途での利用有無
  • セキュリティ監査やコンプライアンスチェックでの利用有無

2.コスト削減可否の検討

手順1.ストレージ利用情報の収集の確認情報をもとに、各バケットに対しての設定、要件の見直しを検討する。

3.バケットの設定変更

3-1.ストレージクラスの変更

手順1.ストレージ利用情報の収集の確認情報をもとに、各オブジェクトに対するストレージクラスの要件を検討し、以下の手順に従ってストレージクラス設定の変更を実施する。

サービス一覧から「Amazon S3」を選択する。「バケット」画面にて対象のバケットを選択し、「アクション」＞「ストレージクラスを変更」を押下する。

見直した要件に沿って、選択肢から変更先を指定する。ストレージクラスの検討においては、以下のAWS公式ドキュメントを参照すること。

• Amazon S3 ストレージクラスの理解と管理
  https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/storage-class-intro.htmlopen_in_newOpens in new tab

※上述の方法では、オブジェクト単位でのクラス変更しか対応していないため、必要に応じて手順3-2.ライフサイクルルールの設定にて「オブジェクトの作成から1日後にクラスの移行」等のルールを適用して対応すること。

3-2.ライフサイクルルールの設定

手順1.ストレージ利用情報の収集の確認情報をもとに、各バケット、オブジェクトに対するライフサイクルルールの要件を検討し、ストレージクラス設定の変更を実施する。

手順は「⑤不要なログの削除」の手順3-2.ライフサイクルルール設定の変更 - S3を参照すること。

1-1.Oracle Cloudコンソールへのログイン

対象システムが稼動するOCIテナンシにAdminユーザーでログインする。

ガバメントクラウドのAdminユーザーはCloud Advisorを操作する権限を有している。

1-2.Cloud Advisorの有効化

ナビゲーション・メニューを開き、「ガバナンスと管理」を選択し、「クラウド・アドバイザ」を選択する。

クラウド・アドバイザが有効な場合、以下のようなコスト管理の推奨事項が表示される。

クラウド・アドバイザが無効の場合は、アクティブ化し有効にする。

なお、クラウド・アドバイザは対象となるリソースが作成されるか、テナンシーにログインすることで自動的に有効化され、7日後から推奨事項を提供する。

図 22 Oracle Cloud Advisorの有効化

1-3.推奨事項の確認

「クラウド・アドバイザ」で、「推奨事項」を選択する。

デフォルト設定では、「すべてのカテゴリ」、「すべてのサービス」および「アクティブ」ステータスの推奨事項が表示される。

推奨のリストをフィルタするには、「カテゴリ」、「サービス」および「ステータス」ボックスを選択して、表示する推奨を表示する。

コスト最適化のための推奨事項を確認するには、「カテゴリ」で「コスト管理」を選択する。

図 23 Oracle Cloud Advisor 推奨事項の確認

1-4.コスト削減内容の確認

「推奨事項のタイプ」から確認したい推奨事項の名前を選択し、推奨事項の詳細ページを開く。

対象のコンパートメントを選択し、必要に応じて「タグ」や「リージョン」でフィルタする。

表示される「Resource recommendations」から、リソース名、推定節約額や推奨構成等を確認することができる。

図 24 Oracle Cloud Advisor 推奨事項のフィルタ

1-5.推奨事項一覧のエクスポート

「CSVをダウンロード」を選択し、ページに表示される推奨事項情報の表をダウンロードする。

なお、手順1-3「推奨事項の確認」にてフィルターを設定している場合は、フィルターされた推奨事項のみがダウンロードされる。

ファイルは指定したダウンロード・フォルダに格納される。

図 25 Oracle Cloud Advisor 推奨事項のエクスポート

1-1.Monitoringの確認

ナビゲーション・メニューを開き、「監視および管理」を選択する。「モニタリング」で、「サービス・メトリック」を選択する。

なお、ガバメントクラウドのAdminユーザーはリソースをモニターするための権限を有している。

権限の詳細は以下のOCI公式ドキュメントを参照すること。

• モニタリングの保護
  https://docs.oracle.com/ja-jp/iaas/Content/Security/Reference/monitoring_security.htm#iam-policiesopen_in_newOpens in new tab

1-2.メトリック・チャートの表示

「サービス・メトリック」ページでサービスごとやリソースごとのメトリック・チャートを確認することができる。

• 「コンパートメント」から、メトリック・データを必要とするリソースを含むコンパートメントを選択する。
• 「メトリック・ネームスペース」リストから、対象のリソース・タイプのメトリック・ネームスペースを選択する。
  たとえば、oci_computeagentを選択して、コンピュート・インスタンスのメトリックを表示する。
• 「ディメンション」から、resourceDisplayNameなどリソース固有のディメンションによるフィルタを追加して、リソースごとのメトリックを表示する。

図 26 メトリック・チャートの表示

• コンピュート・インスタンスに関するメトリック例：
  • CPU使用率
  • メモリー使用率
  • ディスク読取り/書き込みI/O

※「開始時間」「終了時間」を選択して、5分単位で表示期間を変更できる。曜日単位の確認、時間帯ごとの確認等、パターンごとに期間を変更して利用状況を確認すること。

1.コンピュート・インスタンスの変更

1-1.コスト削減可否の検討

「＜共通＞Cloud Advisorによる推奨事項確認」「＜共通＞Monitoringによるリソース利用状況確認」で確認した推奨事項、リソース状況を基にコスト削減の可否を検討する。
CPU利用率やメモリー使用率が定常的に低いコンピュート・インスタンスはスペックが過剰となっている可能性がある。

1-2.インスタンスの縮小

必要以上に大きいコンピュート・インスタンスのOCPU、メモリを縮小することでコストを節約する。

シェイプの変更手順は以下のOCI公式ドキュメントを参照すること。

• インスタンスのシェイプの変更
  https://docs.oracle.com/ja-jp/iaas/Content/Compute/Tasks/resizinginstances.htmopen_in_newOpens in new tab

また、Cloud Advisorで「利用率の低いコンピュート・インスタンスの縮小」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

• 推奨事項の実装
  https://docs.oracle.com/ja-jp/iaas/Content/CloudAdvisor/Tasks/bulk-apply-recommendations.htmopen_in_newOpens in new tab

1-3.バースト可能なインスタンスに変更

コンピュート・インスタンスをバースト可能なインスタンスに変更することで、不定期に使用量が増加するインスタンスにおいてワークロードの増加時にパフォーマンスを低下させることなく、ワークロードが低い通常時にコストを節約する。

バースト可能なインスタンスへの変更手順は以下のOCI公式ドキュメントを参照すること。

• バースト可能なインスタンス
  https://docs.oracle.com/ja-jp/iaas/Content/Compute/References/burstable-instances.htmopen_in_newOpens in new tab

また、Cloud Advisorで「コンピュート・インスタンスをバースト可能に変更」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

• 推奨事項の実装
  https://docs.oracle.com/ja-jp/iaas/Content/CloudAdvisor/Tasks/bulk-apply-recommendations.htmopen_in_newOpens in new tab

図 27 Cloud Advisor レコメンデーションの確認

図 28 Cloud Advisor バースト可能への変更

2.Oracle Databaseの変更

2-1.コスト削減可否の検討

「＜共通＞Cloud Advisorによる推奨事項確認」「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。

• データベースに関するメトリック例：
  • AverageActiveSessions（平均アクティブセッション数）
  • ConnectionLatency（接続レイテンシ）
  • CpuUtilization（CPU使用率）

2-2.データベースの最適化

データベースに必要以上に割り当てられたOCPUを減らすことでコストを削減する。
サービスごとの最適化手順はOCI公式ドキュメントを参照すること。

• Autonomous Database

  • CPUまたはストレージ・リソースの追加または自動スケーリングの有効化
    https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/autonomous-add-resources.html#ADBSB-GUID-DA72422A-5A70-42FA-A363-AB269600D4B0open_in_newOpens in new tab

• Base Database

  • DBシステムのシェイプの変更
    https://docs.oracle.com/ja/cloud/paas/base-database/shape-dbs/open_in_newOpens in new tab

また、Cloud Advisorで「利用率の低いADWおよびATPデータベースの縮小」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

• 推奨事項の実装
  https://docs.oracle.com/ja-jp/iaas/Content/CloudAdvisor/Tasks/bulk-apply-recommendations.htmopen_in_newOpens in new tab

3.リソースの削除

「＜共通＞Cloud Advisorによる推奨事項確認」で確認した推奨事項をもとに、対象のインスタンスの停止・削除を検討する。

検討にあたって、「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を鑑みること。

稼働時間をスケジューリングすることで過剰リソースが解消される場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

1.コスト削減可否の検討

「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。
特定の曜日や時間帯に処理が発生していないリソースは、リソースが不要なときに自動的に停止し必要なときに再起動するよう設定することで、稼働時間を最適化する余地がある。

2.スケジュール停止・起動の実装

該当するリソースの稼働時間や要件を見直し、曜日・時間帯でのスケジュール停止の実装を検討する。

スケジュール停止の実装にあたっては、リソース・スケジューラ等による自動化を検討すること。

リソース・スケジューラでは、次のリソース・タイプに対しスケジュールを作成することができる。

• コンピュート・インスタンス
• コンピュート・インスタンス・プール
• Autonomous Databases
• ファンクション・リソース

リソース・スケジューラのサービス詳細は以下のOCI公式ドキュメントを参照すること。

• リソース・スケジューラ
  https://docs.oracle.com/ja-jp/iaas/Content/resource-scheduler/home.htmopen_in_newOpens in new tab

なお、インスタンス起動時に、稀に一時的なキャパシティ不足のエラーによりインスタンス起動が失敗する可能性があるため、起動のリトライの処理を含めた自動化を行う等の対応をあわせて検討すること。また、スケジュールによる停止起動の対象とするインスタンスについては、コスト削減効果と上記エラー等による起動失敗時の業務影響度を総合的に勘案の上、決定すること。

キャパシティ不足のエラーを踏まえた停止・起動の運用の考え方については、今後GCASガイド上で提供予定のため、そちらを参照されたい。

1.コスト削減可否の検討

「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。
必要以上にスループットの高いストレージではスペックが過剰となっている可能性がある。操作数に対するスペックの妥当性を鑑みて対象リソースを判断する。

• ボリュームに関するメトリック例：
  • ボリューム読取り/書込みスループット
  • ボリューム読取り/書込み操作

2. ブロックボリュームの最適化

2-1. パフォーマンス・レベルの変更

「1.コスト削減可否の検討」の検討結果に基づき、ボリュームのパフォーマンス・レベルを変更する。

パフォーマンス・レベルの変更手順は以下のOCI公式ドキュメントを参照すること。

• 既存のブロック・ボリュームのパフォーマンスの変更
  https://docs.oracle.com/ja-jp/iaas/Content/Block/Concepts/update-performance-block-bv-volume.htmopen_in_newOpens in new tab
• 既存のブート・ボリュームのパフォーマンスの変更
  https://docs.oracle.com/ja-jp/iaas/Content/Block/Concepts/update-performance-boot-bv-volume.htmopen_in_newOpens in new tab

図 29 ボリューム・パフォーマンスの確認

また、ブロック・ボリュームでは動的パフォーマンス・スケーリング（自動チューニング）を有効化することでパフォーマンス・レベルを自動的に調整してパフォーマンスを最適化することができる。

動的スケーリングの詳細は以下のOCI公式ドキュメントを参照すること。

• 動的パフォーマンス・スケーリング
  https://docs.oracle.com/ja-jp/iaas/Content/Block/Tasks/autotunevolumeperformance.htmopen_in_newOpens in new tab

なお、Cloud Advisorのパフォーマンスに関する推奨事項で「デタッチ済ブロック・ボリュームのパフォーマンス自動チューニングの有効化」「デタッチ済ブート・ボリュームのパフォーマンス自動チューニングの有効化」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

• クラウド・アドバイザの推奨事項の実装
  https://docs.oracle.com/ja-jp/iaas/Content/CloudAdvisor/Tasks/implementing_cloud_advisor_recommendations.htm#cloud_advisor-implementing_cloud_advisor_recommendationsopen_in_newOpens in new tab

• パフォーマンスの推奨事項

2-2. アタッチされていないリソースの削除

ブロック・ボリュームは使用していなくてもリソースを確保しており、常にコストが発生し続ける。

アタッチされていないボリュームを削除することでコストを削減する。

手順は以下のOCI公式ドキュメントを参照すること。

• ブロック・ボリュームの削除
  https://docs.oracle.com/ja-jp/iaas/Content/Block/Tasks/deletingavolume.htmopen_in_newOpens in new tab
• ブート・ボリュームの削除
  https://docs.oracle.com/ja-jp/iaas/Content/Block/Tasks/deletingbootvolume.htmopen_in_newOpens in new tab

また、Cloud Advisorで「アタッチされていないブロック・ボリュームの削除」「アタッチされていないブート・ボリュームの削除」が推奨されている場合は、推奨事項の詳細からリソースを修正することができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

• 推奨事項の実装
  https://docs.oracle.com/ja-jp/iaas/Content/CloudAdvisor/Tasks/bulk-apply-recommendations.htmopen_in_newOpens in new tab

1.コスト削減可否の検討

「＜共通＞Cloud Advisorによる推奨事項確認」「＜共通＞Monitoringによるリソース利用状況確認」で確認した推奨事項、リソース状況を基にコスト削減の可否を検討する。

特に、Cloud Advisorにおける「アイドル・コンピュート・インスタンスの削除」の推奨事項は、一部のコンピュート・インスタンスが使用されていないことを示す。

2.リソースの削除

確認したリソース状況をもとに、定常的に利用が確認できないインスタンスは削除候補として検討する。

削除前に一定期間インスタンスを停止し、業務影響を確認することを推奨する。インスタンスを停止している間、OCPU,、メモリに対しては課金されない。

稼働時間をスケジューリングすることで不要なリソースを最適化可能な場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

また、Cloud Advisorで「アイドル・コンピュート・インスタンスの削除」が推奨されている場合は、推奨事項の詳細からリソースを修正することができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

• 推奨事項の実装
  https://docs.oracle.com/ja-jp/iaas/Content/CloudAdvisor/Tasks/bulk-apply-recommendations.htmopen_in_newOpens in new tab

1.ログの利用要件の確認

各ログに関して、業務における利用状況や規定等の要件を確認する。

• 確認事項の例
  • 規制や法令に基づくセキュリティ要件や保持義務の有無
  • アラートや可視化等の運用・監視用途での利用有無
  • セキュリティ監査やコンプライアンスチェックでの利用有無

2.Loggingの最適化

2-1.サービス・ログの保持期間の設定

サービス・ログは対応しているサービスごとに有効にすることで取得される。

保持期間は1か月（デフォルト）から6か月まで30日刻みで設定することが可能である。

ナビゲーション・メニューを開き、「監視および管理」を選択する。「ロギング」で、「ログ」を選択する。

各カスタムログの「編集」を選択し、ログの保持期間を変更する。

その他のログ管理操作については以下のOCI公式ドキュメントを参照すること。

• ログ管理
  https://docs.oracle.com/ja-jp/iaas/Content/Logging/Task/log-management.htmopen_in_newOpens in new tab

なお、コネクタを利用してLoggingからObject Storageにログを転送することでより安価にログを保存できる。

参照する機会が少ないが永続的に保存する必要があるログはObject Storageへの保存も検討する。

コネクタの作成方法は以下のOCI公式ドキュメントを参照すること。

• コネクタ
  https://docs.oracle.com/ja-jp/iaas/Content/Logging/Concepts/connectors.htmopen_in_newOpens in new tab

図 30 ログ保持期間の変更

1.オブジェクトストレージの見直し

1-1.コスト削減可否の検討

「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。

オブジェクト数やバケット・サイズが大きい場合は不要なオブジェクトやバージョンが保存されていないか確認する。

また、リクエスト数の少ないバケットではライフサイクル・ポリシーを設定してオブジェクトのストレージ階層を変更できないか検討する。

• オブジェクトストレージに関するメトリック例：

  • ObjectCount（オブジェクト数）

  • StoredBytes（バケット・サイズ）

  • AllRequests（すべてのリクエスト）*

    *カスタムメトリックであるため、チャートに表示するためにはメトリック・エクスプローラを使用する。

手順は以下のOCI公式ドキュメントを参照すること。

• オブジェクト・ストレージ・バケットのメトリック・エクスプローラを使用したカスタム問合せメトリック・チャートの表示
  https://docs.oracle.com/ja-jp/iaas/Content/Object/Reference/objectstoragemetrics_topic-view_custom_query.htm#consoleopen_in_newOpens in new tab

1-2.バケット内オブジェクトの利用要件の確認

各バケット、オブジェクトに関して、業務における利用状況や規定等の要件を確認する。

• 確認事項の例
  • 規制や法令に基づくセキュリティ要件や保持義務の有無
  • アラートや可視化等の運用・監視用途での利用有無
  • セキュリティ監査やコンプライアンスチェックでの利用有無

1-3.オブジェクト・ライフサイクル・ポリシーの設定

オブジェクト・ライフサイクル管理を使用して、オブジェクト・ストレージおよびアーカイブ・ストレージのデータを管理することでコストを削減する。

ライフサイクル管理の手順は以下のOCI公式ドキュメントを参照すること。

• オブジェクト・ストレージ・オブジェクト・ライフサイクル管理
  https://docs.oracle.com/ja-jp/iaas/Content/Object/Tasks/usinglifecyclepolicies.htmopen_in_newOpens in new tab

また、Cloud Advisorで「オブジェクト・ライフサイクル管理の有効化」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

• 推奨事項の実装
  https://docs.oracle.com/ja-jp/iaas/Content/CloudAdvisor/Tasks/bulk-apply-recommendations.htmopen_in_newOpens in new tab