2025年2月アーカイブ


  1. はじめに
  2. 信頼できるSRE業者の特徴
  3. SRE業者選定時の注意点
  4. まとめ


1.はじめに

近年、システムの安定性と運用効率を向上させるためにSRE(Site Reliability Engineering)を導入する企業が増えています。しかし、SREの導入には専門知識と経験が必要であり、適切な業者を選定することが成功の鍵を握ります。本記事では、SRE導入において信頼できる業者の選び方と注意すべきポイントを解説します。


2.信頼できるSRE業者の特徴

2-1. 豊富な実績と専門知識

SREはシステムの可用性や信頼性を高めるためのエンジニアリング手法であり、経験豊富な業者を選ぶことが重要です。過去の導入実績や成功事例を確認し、特定の業界やシステムにおけるノウハウを持っているかを見極めましょう。


2-2. 自社の課題に合わせた提案ができる

単にSREの原則を適用するのではなく、企業ごとの運用課題に応じたカスタマイズができる業者が望ましいです。初期のコンサルティングで具体的な課題を共有し、どのような施策を提案してくれるか確認しましょう。


2-3. 生成AIなど最新技術の活用

SREでは自動化が重要な要素の一つです。最新の技術を活用し、モニタリングや障害対応の自動化を推進できる業者を選ぶことで、運用負荷を軽減できます。


2-4. SLA(サービスレベルアグリーメント)の明確化

業者の信頼性を判断する上で、提供されるSLAが明確かどうかを確認することが重要です。どの程度の可用性や復旧時間が保証されているのかを事前にチェックし、自社の求める水準と合致しているか検討しましょう。


2-5. セキュリティとコンプライアンス対応

SREの導入においては、セキュリティ対策も不可欠です。業者が適切なセキュリティポリシーを持っているか、また、ISO27001などの認証を取得しているかを確認することで、安全な運用を実現できます。


3.SRE業者選定時の注意点

3-1. 価格だけで判断しない

SREは単なるアウトソーシングではなく、長期的なパートナーシップが求められます。安価な業者を選ぶと、必要なスキルやサポートが不足する可能性があるため、コストだけでなくサービス内容を総合的に評価しましょう。


3-2. 内製化支援の有無

将来的にSREを自社内で運用したい場合、業者が内製化を支援してくれるかも重要なポイントです。ドキュメントの提供や社内エンジニアへのトレーニングを実施してくれる業者を選ぶと、よりスムーズな移行が可能になります。


3-3. 既存システムとの親和性

業者が提案するツールやプロセスが、自社の既存システムと適合するかを確認しましょう。例えば、既存の監視ツールと連携可能か、導入に伴うシステム変更の影響はどの程度かなどを事前に検討することが大切です。


3-4. 継続的な改善提案ができるか

SREは一度導入して終わりではなく、継続的な改善が求められます。業者が定期的なレビューやパフォーマンス分析を行い、改善策を提案してくれるかを確認することで、長期的な運用の質を向上させることができます。


4.まとめ

SRE導入において信頼できる業者を選ぶには、実績や提案力、最新技術の活用、セキュリティ対応などを総合的に判断することが重要です。単なる外注ではなく、長期的なパートナーとして共に成長できる業者を選ぶことで、より効果的なSRE運用が実現できます。

アクセルユニバースではお客様ごとの当初は見えていなかった課題も含め、それぞれのニーズに合致したSREを実現しています。また、生成AIを活用したSRE運用を提供し、障害予測や自動復旧、業界ごとの最適なSRE戦略を提案しています。SRE導入を検討している企業は、ぜひアクセルユニバースのサービスも参考にしてみてください。

SREの導入を成功させるためには、適切な業者選びが欠かせません。慎重に業者を選定し、自社に最適なSRE運用を実現しましょう。


  1. はじめに
  2. SLA、SLO、SLIの定義と相互関係
  3. SLA、SLO、SLIが連携して品質管理を実現する流れ
  4. これらの連携がSREにおいて重要な理由
  5. SLA、SLO、SLIの考え方を練習しよう
  6. まとめ


1.はじめに

SRE(Site Reliability Engineering)は、Googleが提唱した運用手法で、システムやサービスの安定性と信頼性を高め、サービス停止や障害を防ぐことで顧客にとって高品質な体験を提供することを目的としています。その中で、SLA(Service Level Agreement)、SLO(Service Level Objective)、SLI(Service Level Indicator) の3つは、品質管理を支える重要な柱となっています。それぞれが異なる役割を持ちながら密接に関連し合い、SREの実践において欠かせない要素です。これらについて、ピザ配達サービスと電車運行サービスを例に、一緒に理解を深めていきましょう。


2.SLA、SLO、SLIの定義と相互関係

SLA、SLO、SLI の定義を押さえ、ピザ配達サービスの事例で具体的に考えてみましょう。


2-1.SLA(Service Level Agreement: サービスレベル契約)

SLAは、サービス提供者と利用者(顧客)との間で交わされる契約です。具体的には、サービスがどのように提供されるかを明示し、顧客に対して「どの程度信頼できるのか」を示します。

目的

サービス提供者は提供すべきサービスレベルを明確にし、利用者は受け取るサービスの品質を理解することができるため。

ピザ配達サービスの例

ピザチェーン店が「90%以上の注文を30分以内にお届けします」と顧客に約束する。

この「30分以内に90%以上の注文を届ける」という約束がSLAです。これにより、顧客は「自分の注文が確実に時間内に届く可能性が高い」という具体的な期待を持つことができます。同時に、ピザチェーン店にとっては、サービスの信頼性を顧客に示すことで、競合他社との差別化を図り、リピーターの獲得につなげる重要な要素となります。例えば、配達が30分を超えるケースが10%を超えると、SLAの達成が困難になります。その場合、運用を見直す必要があると判断できます。このように、SLAは顧客との約束であると同時に、サービス提供者自身が信頼性を維持・向上させるための目安ともなるのです。


2-2.SLO(Service Level Objective: サービスレベル目標)

SLOは、サービス提供者がSLAを守るために内部で設定する目標値です。これは具体的な基準であり、達成することでSLAを実現します。

目的

内部で達成すべき品質目標を設定し、運用方針を明確化する。

ピザ配達サービスの例

配達スタッフが「95%以上の注文を25分以内に届ける」という目標を設定する。

SLAを守るには、少し厳しめの内部目標(SLO)を設ける必要があります。これは、予期せぬトラブルや運用上のばらつきに備えるためです。例えばピザ配達サービスでは、悪天候や交通渋滞、注文の集中など、配達時間が遅れてしまう要因が発生することがあります。これらの影響を考慮し、SLOを「95%以上の注文を25分以内に届ける」といった厳しめの基準に設定することで、運用に余裕を持たせ、万が一の事態にもSLAが守られる確率を高めることができるようにしています。

また、SLOは単なる目標ではなく、運用チーム全体の努力の指針となるものです。SLOを明確にすることで、調理や配達のプロセスの見直し、配達員の配置の最適化、ルート計画の改善など、チーム全体が具体的な改善策に取り組みやすくなります。このように、SLOはSLAを達成するための「現実的かつ挑戦的な基準」として、サービス運用の質を向上させる重要な役割を果たしています。


2-3.SLI(Service Level Indicator: サービスレベル指標)

SLIは、サービスの状態を測定するための具体的なデータや数値です。このデータをもとに、SLAやSLOの達成状況を確認します。

目的

サービスの品質を数値で把握し、問題点を明確にする。

ピザ配達サービスの例

実際に注文が配達されるまでの時間を件数で割った平均配達時間や25分以内の配達成功率、25分超えの遅延率を算出する。

このデータは、SLOが達成されているかを判断するための根拠として重要です。もしSLI(例えば25分以内の配達率)が「95%」を下回った場合、配達が遅れた注文の具体的な原因を分析することで、運用上の問題点を明確にできます。例えば特定の時間帯やエリア、配達手段によって遅延が多い場合、それに対応した改善策を講じることが可能です。

また、SLIは単なる記録ではなく、サービスの改善に直接つながるデータです。例えば、配達成功率のデータを継続的にモニタリングすることで、運用の改善が進んでいるかを確認できます。さらに、SLIを複数の指標で測定する(例: 配達成功率、平均配達時間、配達温度の適正率など)ことで、サービスの品質を多面的に把握でき、顧客体験をより向上させるためのヒントを得ることができます。SLIはサービスの現状を「見える化」し、継続的に品質向上を支える重要な役割を担っています。


3.SLA、SLO、SLIが連携して品質管理を実現する流れ

結果をもとに継続的改善を実施

SLIのデータがSLO(目標)を下回っている場合、原因を特定し改善施策を実行します。これにより、SLA(顧客との約束)を守り続ける仕組みが実現します。

・配達エリアが広範囲にわたり、一部の遠距離配達が25分以内に間に合わない。

 →配達エリアを再定義し、範囲を縮小。遠距離の注文は別店舗に割り振る。

・配達ルートの最適化不足

 →地域ごとの渋滞情報をリアルタイムで共有し、配達ルートを柔軟に変更できる仕組みを整備。

このようにSLAを達成できるように継続的改善を行います。


4.これらの連携がSREにおいて重要な理由

4-1.信頼性の向上

SLAを守ることで、顧客にとってサービスの信頼性が高まります。また、SLOを目標に運用を管理し、SLIを測定し続けることで、サービスの品質を継続的に向上させることができます。


4-2. トラブルの早期発見と対応

SLIを定期的にモニタリングすることで、SLOの目標を下回る兆候をいち早く察知できます。これにより、SLAを破る可能性のあるトラブルを未然に防ぐことが可能です。


4-3. 顧客満足度とビジネス成長の両立

SLA、SLO、SLIを活用することで、顧客が求める品質を維持しながら、サービス提供者にとっても効率的な運用が実現します。このバランスが取れることで、顧客満足度が向上し、ビジネスの成長にもつながります。

SREのメリット


5.SLA、SLO、SLIの考え方を練習しよう

ピザ配達サービスの事例を通じて基本概念を学びました。それではこの知識を応用して、電車運行サービスにおけるSLA、SLO、SLIを一緒に考えてみましょう。ピザ配達サービスと電車運行サービスの違いに注目しながらどのように適用されるのかを整理していきます。


5-1. 電車運行サービスにおけるSLA

電車の場合、「時間通りに運行されること」 や 「大きな遅延が発生しないこと」 が乗客の期待になると考えられます。この点をふまえ、電車運行サービスにおけるSLAを考えてみましょう。

さて、以下のSLAを考えてみましたが、皆さんはどのようなSLAを考えたでしょうか?

例:電車運行サービスのSLA

(1)平日の通勤ラッシュ時(朝7時~9時)、運行遅延率を5%未満に抑えます。

(2)30分以上の遅延発生率を1%未満に抑えます。

(3)運行中止時、15分以内に代替交通手段を提供し、適用対象の乗客へ電子クーポンを発行する。


考えてみよう①

SLAを設定する際、ピザ配達サービスと電車運行サービスでは、それぞれ何に気をつける必要があるでしょうか?

この2つのサービスでは、顧客の期待や求められる品質保証の内容が異なります。

ピザ配達は個々の顧客に迅速なサービスを提供することが最優先されるのに対し、電車運行は多くの乗客に対する安定した輸送の維持が目的となるため、SLAの性質や補償の内容が大きく異なります。


5-2.電車運行サービスにおけるSLO

SLOは、SLAで約束した基準を守るために、鉄道会社が内部で設定する具体的な目標値です。SLOは、運行管理チームや運転士、システム運営チームが共有する「実現可能で挑戦的な基準」として機能します。皆さんは上記のSLAに対して、どんなSLOを考えますか?

さて、以下のSLOを考えましたが、皆さんはどのようなSLOを考えたでしょうか?

例:電車運行サービスのSLO

(1)平日の通勤ラッシュ時(朝7時~9時)、運行遅延率を3%以下に維持する。

(2)30分以上の遅延発生率を0.5%以下に抑える。

(3)運行中止時、15分以内に振替輸送を提供し、適用対象の乗客へ電子クーポンを発行する。


考えてみよう②

電車運行サービスのSLOでは何を重視して目標を設定することが考えられるでしょうか?候補は様々ありますが、上記の3つのSLOでは何を重視しているのか考えてみましょう。

上から順番に、平日通勤ラッシュ時の定時運行の維持、大規模遅延の抑制、サービス継続性と緊急時対応と考えられます。


5-3. 電車運行サービスにおけるSLI

SLIは、SLOの達成状況を確認するための測定データです。鉄道会社は、運行状況を数値で記録し、どの程度SLOを守れているかを継続的にモニタリングします。これにより、SLAが達成されているかどうかを判断できます。上記のSLOに対しては、以下のSLIが考えられます。

例:電車運行サービスのSLI

(1)通勤ラッシュ時の運行遅延率

例)朝のラッシュ時に200本の電車が運行され、そのうち6本が5分以上遅延

→ 遅延率 = (6 ÷ 200) × 100 = 3.0%(SLO達成)

(2)30分以上の遅延発生率

例)1日1000本の電車のうち、4本が30分以上遅延

→ 遅延発生率 = (4 ÷ 1000) × 100 = 0.4%(SLO達成)

(3)振替輸送手配完了時間

例) 1か月間で3回の運行中止が発生し、対応完了時間が9分・8分・10分

→ 平均 = 9分(SLO達成)

例えば、運行管理システムでは、全電車の出発時刻と到着時刻を記録して、運行遅延率や運行遅延発生率を計測します。このSLIデータを基にどの程度SLOが達成され、結果としてSLAが守られているかを把握できます。


5-4.SLA、SLO、SLIが連携して電車運行を支える仕組み

これらの3つは、それぞれ異なる役割を持ちながらも、緊密に連携して機能します。

・SLA : 乗客に対する明確な約束

・SLO : その約束を守るための内部目標

・SLI : 目標達成状況を確認するための指標

電車運行サービスでは、多くの乗客が予定どおりに移動できるよう、定時運行・大規模遅延の防止・運行中止時の対応 といった要素が求められます。そのために、SLA、SLO、SLIが連携し、運行の品質を維持・向上させる役割を果たします。

ただし、電車の運行においては「安全性」「コスト最適化」など、様々な要素を考慮しながらバランスを取る必要があります。どの指標を重視するかは、サービス内容や提供者の方針によって異なります。

例) 安全性を最優先する場合

→ 遅延よりも、保守・点検の頻度を増やし、安全基準を強化する。

例)コストを最適化する場合

→ 遅延が多少発生しても、運行本数を削減し、効率的な運行を重視する。

このように、SLA、SLO、SLIの設定はサービスの特性によって異なり、それぞれの目的に応じた最適な指標を選ぶことが重要です。

SREのメリット


6.まとめ

SLA、SLO、SLIは、サービスの品質を維持し、信頼性を高めるために欠かせない基本概念です。それぞれの役割を正しく理解し活用することで、トラブルを未然に防ぎ顧客の期待を超えるサービスを提供できるようになります。これまで、ピザ配達サービスや電車運行サービスの例を通じて、SLA、SLO、SLIがどのように品質管理に活用されるかを考えてきました。

SREはこれらの概念を土台に、システムやサービスの安定性を高めるアプローチを提供します。ピザ配達サービスや電車運行サービスの事例で考えてきたように、「顧客への信頼」を「数値と目標」に落とし込み、それを「データで実現」する仕組みを作ります。

システム運用に対しSREを導入することで、次のようなメリットを実現できます。

・サービスのトラブル発生率を低下させ、信頼性向上。

・明確な目標とデータ測定に基づく運用の効率化。

・顧客や社内ユーザーからの信頼を得られるシステムの提供。

SLA、SLO、SLIを活用する第一歩として、現在運用しているシステムの「目標(SLO)」と「測定指標(SLI)」を明確にしてみてください。それに基づいて「どんな約束(SLA)を実現するべきか」を考えることで、SREの考え方を実践的に取り入れることができます。



X(旧Twitter)・Facebookで定期的に情報発信しています!


  1. はじめに
  2. AWS Compute Optimizerとは?
  3. 対象リソースについて
  4. AWS Compute Optimizerの採用メリット
  5. AWS Compute Optimizerの採用デメリット
  6. 実装ステップ:AWS Compute Optimizerを有効化する方法
  7. AWS Compute Optimizerの導入で次の一歩を踏み出そう


1.はじめに

AWSのリソースコストを削減したいと考えていても、「会社のアカウント情報を第三者に見せるのはちょっと...」と不安に感じる方は多いと思われます。そこで安心して始められるコスト最適化の第一歩として、AWS Compute Optimizerをご紹介します。このツールは、専門知識がなくてもAWSのリソース利用状況を可視化し、最適化案を提案してくれる頼れる存在です。今回の記事では、このCompute Optimizerの仕組みや具体的なメリット、注意点を分かりやすくお伝えします。さらに、記事の最後ではコスト削減施策を次のステージに進めるための実践的なステップもご紹介しますので、ぜひ最後までご覧ください。


2.AWS Compute Optimizerとは?

AWS Compute Optimizerは、AWSリソースの設定と使用率メトリクスを分析し、最適なリソースサイズを提案するサービスです。このツールを使えば、現在使用中のリソースが過剰なスペックを持つ、または逆にスペック不足でパフォーマンスに影響を与えているかを簡単に判断できます。

主な特徴は以下の通りです。

視覚的なダッシュボードでリソースの使用状況を確認
最適化レコメンデーションを最大3件提供
対象リソースのコストやパフォーマンスの最適化を支援

AWS Compute Optimizerは無料プランと有料プランがあり、それぞれ異なるデータ分析期間をサポートします。

・無料プラン : 過去14日間のデータ分析

・有料プラン : 過去90日間の詳細データ分析(料金はリソース1時間あたり0.0003360215USD)


3.対象リソースについて

AWS Compute Optimizerでは、最適化の推奨事項を提供する対象が決まっています。対象となるのは、以下8個の主要リソースです。(2025年1月時点)

1. Amazon EC2 インスタンス

2. Amazon EC2 Auto Scaling グループ

3. Amazon EBS ボリューム

4. AWS Lambda 関数

5. Amazon ECS on Fargate サービス

6. 商用ソフトウェアライセンス

7. Amazon RDS インスタンス

8. Amazon RDS ストレージ

ただし、推奨事項を得るためには、2つ注意点があります。それについては、後の5. AWS Compute Optimizerの採用デメリットで詳しく触れたいと思います。


4.AWS Compute Optimizerの採用メリット

AWS Compute Optimizerを活用すると、単なるコスト削減にとどまらず、パフォーマンスの向上や運用の効率化といった幅広いメリットが得られます。「効率よくAWSリソースを使いたいけれど、何から始めればいいか分からない...」そんなお悩みを抱えている方にとって、最適なツールとなっています。それでは、Compute Optimizerを導入することで得られる主なメリットをご紹介します。


4-1.大幅なコスト削減

AWS Compute Optimizerは、リソースの使用状況を徹底的に分析し、過剰なスペックでコストがかさんでいる場合や、リソースを使いすぎている具体的な状況を教えてくれます。その結果、リソースの最適化を行うことで、AWSコストを最大25%削減することが可能です。例えば、普段気づきにくいオーバープロビジョンされたEC2インスタンスや、実はもっと低コストなストレージオプションで十分なEBSボリュームなど、目からウロコの気づきが得られるかもしれません。


4-2.パフォーマンスの最適化

「スペックが足りなくて処理が遅い」「逆にオーバースペックで無駄が多い」など、運用現場でよくある課題を正確に分析し、最適なスペックやサイズを提案してくれます。


4-3.迅速な導入

AWS Compute Optimizerの魅力の一つは、なんといってもすぐに使えるという手軽さです。AWS Management Consoleで有効化するだけで、レコメンデーションが自動生成され、すぐに最適化案を確認することができます。特別なセットアップやトレーニングも必要なく、まさに「今すぐ始められる」ツールです。AWSの利用経験が豊富な方はもちろん、初めて最適化に取り組む方でも直感的に使える設計になっています。


4-4.エンジニアの工数削減

これまでリソース最適化といえば、エンジニアが膨大な使用率データを分析し、最適なリソースサイズを手作業で見つけ出す必要がありました。Compute Optimizerは、こうした煩雑な作業を自動化します。エンジニアは最適化のためのデータ解析に時間を割く必要がなくなり、本来注力すべきプロジェクトや改善活動に集中することが可能です。結果的に、チーム全体の生産性を向上させることができるだけでなく、運用コストも削減できるという、一石二鳥のメリットを提供してくれます。


5.AWS Compute Optimizerの採用デメリット

どんなに便利なツールにも、効果的に活用するためには理解しておくべき制約があります。AWS Compute Optimizerも例外ではありません。このツールを導入する際に注意したい点を以下にまとめました。


5-1.対象サービスが限定的

AWS Compute Optimizerは、Amazon EC2やEBS、RDSなどの主要なリソースには対応していますが、すべてのAWSサービスを対象にしているわけではありません。たとえば、Amazon S3やDynamoDBなど、重要ながらも対象外となるリソースがあります。そのため、Compute Optimizerだけでは網羅的な最適化が難しい場合があり、場合によっては他のツール(AWS Trusted AdvisorやCost Explorer、Compute Savings Plans)との組み合わせや追加の手動作業が必要になります。


5-2.使用条件がある

Compute Optimizerのレコメンデーションを得るには、リソースが一定の条件を満たしている必要があります。例えば、最低でも過去14日間のメトリクスデータが収集されていることが前提となります。そのため、新しく作成したばかりのリソースや、使用頻度の低いリソースでは、具体的な提案が得られない場合があります。より詳細な分析を行う場合は、最大90日間のメトリクスデータを収集して実施する有料プランとなります。 こうした条件を理解しておくことで、Compute Optimizerの利用効果を最大化できるでしょう。


6.実装ステップ:AWS Compute Optimizerを有効化する方法

AWS Compute Optimizerは、手軽に有効化でき、導入後すぐにリソース最適化の提案を受け取ることが可能です。「具体的な手順が分からなくて不安...」という方のために、実際の画面を使った動画もご用意しましたので、ぜひそちらも参考にしてみてください。

以下では、Compute Optimizerを有効化し、実際にレコメンデーションを適用するまでのステップを簡単に解説します!



1.Compute Optimizerを有効化

AWS Management Consoleで「AWS Compute Optimizer」を検索し、有効化ボタンをクリック。

2.対象リソースを確認

自身の環境で分析対象となるリソース(EC2、EBSなど)を確認し、使用状況メトリクスが十分に収集されているかチェック。

3.ダッシュボードで結果を確認

推奨事項をダッシュボード上で確認し、最適化されたリソースに変更。

4.レコメンデーションの適用

提案された設定をもとに、リソースサイズや設定を調整。


7.AWS Compute Optimizerの導入で次の一歩を踏み出そう

AWS Compute Optimizerを利用することで、リソースのパフォーマンスを向上させながらコスト削減が実現できます。特に、自動化された分析と推奨事項は、運用コストを削減しつつ効率的なリソース利用をサポートしてくれる強力な味方です。

しかし、Compute Optimizerがカバーする範囲は限定的であり、一部のAWSリソースや環境における最適化はサポート外となる場合があります。

そのような網羅できない部分や、より高度な最適化の余地がある場合は、専門家のアドバイスを受けることが理想的です。アクセルユニバースでは、AWSアカウント全体を見渡して包括的なコスト削減を支援するAWSコスト削減チェックリストを提供しています。このチェックリストでは、Compute Optimizerでは対応できない領域もカバーし、さらに具体的で効果的な施策を実現できる内容が含まれています。

AWSのリソース利用をもっと最適化したい方や、現状のコスト削減施策を次の段階に進めたい方は、ぜひ以下のリンクをご覧ください。

AWSコスト削減を叶える18個のチェック項目

コスト最適化を効率的に進めたい方は、お気軽にアクセルユニバースにご相談ください!



X(旧Twitter)・Facebookで定期的に情報発信しています!


  1. 背景
  2. 原因調査
  3. 解決策
  4. 結果


1.背景

AWSを使用する多くの企業にとって、Amazon S3(Simple Storage Service)は最も利用されるストレージサービスの一つです。S3は、スケーラブルで信頼性が高く、データを安全に保存できるため非常に人気があります。しかし、使い方によってはストレージコストが膨らみ、毎月の予算を圧迫する原因にもなります。私たちAUCでは、SRE活動の一環としてAWSのコスト適正化を進めており、特にAmazon S3のコスト削減に焦点を当てました。

私たちがAmazon S3のコストを削減する上で直面した課題は、以下の点に集約されました。

  • データストレージが急激に増加し、不要なデータが放置されている。
  • データのライフサイクルポリシーが適切に設定されていないため、古いデータが自動削除されていない。
  • ストレージクラスを見直していないため、アクセス頻度の低いデータが高コストのストレージクラスに残っている。
  • データ転送の方法が最適化されていないため、予想外の転送料金が発生している。

これらの課題に対処するため、S3のコスト削減を図るための原因調査と最適化を実施しました。

この記事では、Amazon S3のコスト削減に向けた原因調査から解決策までのプロセスを具体的に記録します。


2.原因調査

まず、S3コストの内訳を確認するために、AWS Cost Explorerを活用してコスト分析を行いました。Amazon S3のコストは主に以下の2つの要素に分かれます。

  • データストレージ料金:保存されているデータ量に応じて発生するコスト。
  • データ転送料金:データをインターネットまたは他のAWSサービスへ転送する際に発生するコスト。

私たちの調査結果では、コストが急激に増加している主な原因は、ストレージクラスの選択ミスとデータライフサイクルの適切な管理が行われていなかったことにありました。また、転送コストが予想以上に高くなっていることも確認されました。以下、詳細な分析を進めました。


2-1.不要なデータの放置

長期間アクセスされていないデータが大量にS3バケットに保存されており、これがストレージコストを大幅に押し上げていました。具体的には、あるプロジェクトで使用されていたログデータやバックアップファイルが自動削除されることなく数年間にわたって保存され続けていたのです。


2-2.ストレージクラスの最適化不足

Amazon S3には、アクセス頻度に応じた複数のストレージクラスがあります。アクセス頻度が高いデータは「S3標準(Standard)」に保存されるべきですが、長期間アクセスされないアーカイブデータやバックアップデータに関しては「S3 Infrequent Access」や「S3 Glacier」などの低コストのクラスに移行すべきです。しかし、これが実施されていないために、全データがS3標準クラスに保存され、高いコストが発生していました。


2-3.データ転送の最適化不足

私たちの分析によると、EC2インスタンスからS3へのデータ転送が、VPCエンドポイントを使用せずに行われており、結果としてインターネット経由でデータが転送されていました。この設定ミスにより、不要なデータ転送料金が発生していました。


3.解決策

私たちは、以下のアプローチでS3のコスト削減を実現しました。


3-1.データライフサイクルポリシーの設定

まず、Amazon S3のデータライフサイクルポリシーを設定しました。これにより、特定期間が過ぎたデータを自動的にアーカイブする、あるいは削除することで、不要なデータが永続的に保存されないようにしました。例えば、アクセスされなくなってから90日を経過したデータは「S3 Glacier」に移動し、1年間アクセスがなかったデータは自動削除するように設定しました。

  • S3 Lifecycle Rules:特定のオブジェクトを指定期間後に低コストのストレージクラスに移行する、または削除するポリシーを適用。

これにより、アーカイブデータや古いバックアップデータが適切に管理され、ストレージコストを削減することができました。


3-2.ストレージクラスの見直し

次に、すべてのS3バケットに保存されているデータのアクセス頻度を分析し、ストレージクラスの見直しを行いました。アクセス頻度の低いデータは、「S3 Infrequent Access」または「S3 Glacier」に移行することで、ストレージ料金を大幅に削減しました。

  • S3 Standard:頻繁にアクセスされるデータ。
  • S3 Infrequent Access:アクセス頻度が低いが必要なデータ。
  • S3 Glacier:アーカイブデータ。

また、今後は新しいデータが自動的に適切なストレージクラスに保存されるように設定を行い、運用管理の負担を軽減しました。


3-3.VPCエンドポイントの導入

私たちは、EC2インスタンスとS3間のデータ転送を最適化するために、VPCエンドポイントを導入しました。VPCエンドポイントを利用することで、インターネットを介さずにVPC内部で直接データ転送を行うことができ、データ転送料金を大幅に削減することができました。

  • VPCエンドポイント(Gatewayタイプ):S3との通信をインターネットを介さずに行うことで、データ転送料金を削減。

VPCエンドポイントの利用により、データ転送料金を最大で80%削減することに成功しました。


3-4.S3インテリジェントティアリングの利用

さらに、S3インテリジェントティアリングという機能を活用しました。これにより、アクセスパターンに基づいて自動的にストレージクラスを最適化し、手動での移行作業を減らしました。インテリジェントティアリングは、データのアクセス頻度が減少した際に自動的に低コストのストレージクラスに移行してくれるため、長期間にわたってストレージコストの削減に寄与します。


4.結果

これらの最適化施策により下記の成果を得られました。


4-1.データライフサイクルポリシーの設定によるコスト削減

前提条件

  • 東京リージョン
  • 保存されているデータ量:10TB(10,240GB)
  • データのアクセス頻度は低く、90日後にほとんどアクセスされなくなる


アプローチ

  • 90日後に「S3 Standard」から「S3 Glacier」にデータを移行
  • 年間データを保持後、削除。


コスト計算

  • S3 Standard: 0.023USD/GB/月

→10,240GB × 0.023USD × 3か月 = 706.56USD

  • S3 Glacier Flexible Retrieval: 0.0045USD/GB/月

→10,240GB × 0.0045USD × 9か月 = 414.72USD

合計: 706.56USD + 414.72USD = 1,121.28USD/年


削減前のコスト

もし全データが「S3 Standard」に保存されていた場合 : 10,240GB × 0.023USD × 12か月 = 2,826.24USD/年


削減効果

1,121.28USD/年 vs 2,826.24USD/年 → 約1,705USDの削減(約60%の削減)


4-2.ストレージクラスの見直しによるコスト削減

前提条件

  • 東京リージョン
  • 10TBのデータのうち、頻繁にアクセスされるデータは40%(4TB)、残り60%(6TB)は低頻度


アプローチ

  • 頻繁にアクセスされるデータ(4TB)を「S3 Standard」に保持
  • 低頻度のデータ(6TB)を「S3 Infrequent Access」に移行


コスト計算

  • S3 Standard: 0.023USD/GB/月

→4,096GB × 0.023USD × 12か月 = 1,130.496USD/年

  • S3 Standard Infrequent Access: 0.0138USD/GB/月

→6,144GB × 0.0138USD × 12か月 = 1,017.4464USD/年

合計: 1,130.496USD + 1,017.4464USD = 2,147.9424USD/年


削減前のコスト

すべて「S3 Standard」に保存されていた場合 : 10,240GB × 0.023USD × 12か月 = 2,826.24USD/年


削減効果

2,147.9424USD/年 vs 2,826.24USD/年 → 約678USDの削減(約24%の削減)


4-3.VPCエンドポイントの導入によるデータ転送料金の削減

前提条件

  • 東京リージョン
  • 毎月、10TBのデータをEC2からS3に転送
  • 現在は、インターネット (NAT Gateway) 経由で転送しているため、データ転送料金、およびNAT Gateway配置料金が発生している


アプローチ

  • VPCエンドポイント(Gatewayタイプ)を導入し、インターネット (NAT Gateway) 経由の転送を排除


コスト計算

VPCエンドポイントデータ転送料金 : 0USD

VPCエンドポイント利用料金 : 0USD


削減前のコスト

  • NAT Gatewayデータ転送料金:0.062USD/GB/月

→ 10,240GB × 0.062USD × 12か月 = 7,618.56USD/年

  • NAT Gateway配置料金:0.062USD/時

→ 0.062USD × 8760h = 543.12USD/年

合計: 7,618.56USD + 543.12USD = 8161.68USD/年


削減効果

0USD/年 vs 8161.68USD/年 → 8,162USDの削減(100%の削減)


4-4.S3インテリジェントティアリングの利用によるコスト削減

前提条件

  • 東京リージョン
  • 保存データ:10TB(10,240GB)
  • オブジェクト : 1,000件
  • データアクセスパターン:最初の3か月は頻繁にアクセスされるが、それ以降はほとんどアクセスされない


アプローチ

  • 「S3 Standard」ではなく「S3 Intelligent Tiering」を使用
  • アクセスパターンに基づいて自動的に低コストのストレージクラスに移行


コスト計算

  • S3 Intelligent Tiering:最初の3か月は「S3 Standard」相当、以降は低頻度アクセスストレージに移行

  • 最初の3か月

Frequent Access Tier : 0.025USD/GB/月 → 10,240GB × 0.025USD × 3か月 = 768USD

  • 残りの9か月

Infrequent Access Tier : 0.0138USD/GB/月 → 10,240GB × 0.0138USD × 9か月 = 1,271.808USD

  • オブジェクト1,000件あたりのモニタリング・オートメーション料金 : 0.0025USD/月

0.0025USD × 12か月 = 0.03USD/年

合計: 768USD + 1,271.808USD + 0.03USD = 2,039.838USD/年


削減前のコスト

もし全データが「S3 Standard」に保存されていた場合 : 10,240GB × 0.023USD × 12か月 = 2,826.24USD/年


削減効果

2,039.838USD/年 vs 2,826.24USD/年 → 約786USDの削減(約28%の削減)


4-5.総合的なコスト削減効果

これらのアプローチを総合的に適用することで、S3のコストを大幅に削減することが可能です。

  • データライフサイクルポリシーによる削減: 約1,705USD/年
  • ストレージクラスの見直しによる削減: 約678USD/年
  • VPCエンドポイントの導入による削減: 約8,162USD/年
  • S3インテリジェントティアリングによる削減: 約786USD/年

これにより、合計で年間 約11,331USD の削減が見込めます。特に、データ転送コストの削減が大きなインパクトを与えていますが、データストレージの最適化も重要なポイントです。

今後の課題としては、さらなるデータの最適化と、各部門でのコスト意識の向上が挙げられます。AWSのベストプラクティスに従ったコスト管理を継続し、今後も新たなコスト削減の方法を模索していきます。



X(旧Twitter)・Facebookで定期的に情報発信しています!

このアーカイブについて

このページには、2025年2月に書かれた記事が新しい順に公開されています。

前のアーカイブは2025年1月です。

次のアーカイブは2025年3月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。