1. はじめに
2. 「ゼロトラスト」の考え方を取り入れる
3. 設定ミスを防ぐ！インフラのコード化（IaC）を活用
4. 「監視」と「インシデント対応」の自動化を強化
5. セキュリティパッチの適用を自動化する
6. 社員のセキュリティ意識を高める
7. まとめ

1.はじめに

最近、「クラウドを導入したものの、セキュリティ運用が複雑になって管理が大変...」といったお悩みを耳にすることが増えました。クラウドの柔軟性や拡張性を活かしつつ、どうすればセキュリティリスクを最小限に抑えられるのでしょうか？

そこで今回は SRE（Site Reliability Engineering）の考え方を活用したセキュリティ運用の最適化 について、5つのポイントにまとめました。情報システム部やシステムを管理されている総務部の皆さまに役立つ内容になっていますので、ぜひチェックしてみてください。

2.「ゼロトラスト」の考え方を取り入れる

これまでの企業ネットワークでは、「社内ネットワーク＝安全」「外部＝危険」という境界型セキュリティの考え方が主流でした。

しかし、VPN で社内ネットワークに接続するだけで自由にシステムへアクセスできる環境では、攻撃者が VPN 認証さえ突破すれば、内部のデータや重要なシステムに簡単に侵入できてしまいます。

そこで注目されているのが、ゼロトラスト（Zero Trust）の考え方です。ゼロトラストでは、「何も信用しない（Never Trust、 Always Verify）」を前提に、社内外のすべてのアクセスを検証し、必要最低限​​の権限のみを付与することで、セキュリティリスクを極力抑えます。

ゼロトラストを実現する3つのポイント

ゼロトラストの考え方を企業のセキュリティ運用に取り入れるためには、認証・アクセス制御・権限管理の3つの要素を徹底することが重要です。

check①最小権限の原則（PoLP：Principle of Least Privilege）を徹底
➡ 必要最低限のアクセス権しか与えないことで、万が一の不正アクセス被害を抑えます。

check②多要素認証（MFA）の導入
➡ パスワード＋ワンタイムパスワードなど、複数の認証要素を組み合わせることでセキュリティ強化ができます。

check③端末や場所に応じたアクセス制御
➡ たとえば「日本国内の社用PCからのみアクセス可能」など、細かくルールを設定すると安心です。

ゼロトラストを意識することで、「誰でもどこからでもアクセスできる」リスクを最小限にできます。

※関連記事：VPNリスクの終焉とゼロトラスト時代のセキュリティ運用とは？

3. 設定ミスを防ぐ！インフラのコード化（IaC）を活用

クラウド環境では、設定のわずかなミスが大きなセキュリティリスクにつながることがあります。特に「うっかりパブリックに公開されていた...」といった事態は絶対に避けたいですよね。

そこでおすすめなのが Infrastructure as Code（IaC） を活用した運用です。

Infrastructure as Code（IaC）とは？

Infrastructure as Code（IaC）とは、クラウドのインフラ設定をコードとして管理し、自動的に構築・変更できる仕組みのことです。 クラウド環境では、サーバー・ネットワーク・ストレージなどのインフラを手動で設定するのではなく、プログラムコードとして行わなくても、環境構築の自動化と継続性を確保できます。

check①設定をコード化し、変更履歴を管理
➡ TerraformやAWS CloudFormationを使えば、「誰が」「いつ」「どんな変更をしたか」がすぐにわかるようになります。

check② 自動チェックを組み込み、設定ミスを防ぐ
➡ OPA（Open Policy Agent）やCheckovなどのツールを活用すると、セキュリティポリシーに違反する設定を事前に検出できます。

人手によるミスを減らし、セキュリティを一貫して守れる仕組みを作ることが大切です。

4. 「監視」と「インシデント対応」の自動化を強化

「セキュリティインシデントは起こらないのが理想」ですが、 現実的にはどんなに対策をしても100％防ぐことはできません。 だからこそ、「早く気づいて、すぐに対応する」仕組みが必要です。

check①SEIM（Security Information and Event Management）の活用
➡ AWS GuardDuty、Google Chronicle、Splunkなどを使ってログを集約し、異常を検知できます。

check②ログを一元管理し、自動分析を導入
➡ ELK StackやCloudWatch Logsを活用すると、異常な動きをすぐにキャッチできます。

check③SOAR（Security Orchestration, Automation and Response）の導入
➡ セキュリティインシデントが発生したら、事前に設定したルールに基づいて自動で対処します。（たとえば特定のIPアドレスを即ブロックするなど）

SREの視点では 「インシデントは発生するもの」と捉え、素早く検知し対応できる仕組み を整えることがポイントです。

5. セキュリティパッチの適用を自動化する

クラウド環境では、OSやミドルウェアの脆弱性が次々と発見されます。セキュリティパッチを適用しないと、 攻撃の標的になりやすくなる ので要注意です。

check①自動パッチ適用の仕組みを構築
➡ AWS Systems Manager Patch ManagerやGoogle OS Patch Managementを活用すると、自動でパッチ適用が可能です。

check②脆弱性スキャンツールを活用
➡ Amazon InspectorやAqua Securityを使えば、脆弱性のあるコンポーネントを事前にチェックできます。

「忙しくて対応できなかった...」を防ぐためにも、自動化を取り入れることが重要です！

6. 社員のセキュリティ意識を高める

どんなに技術的な対策を講じても、 人的ミスやフィッシング詐欺による情報漏洩が原因でセキュリティ事故が発生するケースは少なくありません。

check①定期的なセキュリティ研修を実施
➡ フィッシング詐欺の実例を紹介しながら、「自分ごと」として学べる場を作るのが効果的です。

check②セキュリティSLO（Service Level Objective）を設定
➡ たとえば「全社のパスワード変更率90%以上」など、具体的な目標を掲げることで意識向上につながります。

check③インシデント対応の訓練を実施
➡ 「もしも社内で情報漏洩が起きたら？」といったシナリオを想定し、実際に対応できるかシミュレーションを行うとよいでしょう。

結局のところ、 セキュリティは「仕組み」だけでなく「人の意識」も大きく関わるもの。全員で意識を高めていくことが大切です。

7.まとめ

クラウド環境でのセキュリティ運用を最適化するために、SREの視点から 5つのポイント をご紹介しました。

■ ゼロトラストの導入で、不正アクセスを防ぐ
■ 設定ミスを防ぐために、IaCを活用する
■ セキュリティ監視を自動化し、迅速に対応する
■ セキュリティパッチ適用を自動化し、リスクを最小限に
■ 社員のセキュリティ意識を高め、人的ミスを防ぐ

「自社のセキュリティ運用、もっと最適化したい！」という方は、ぜひSREのアプローチを取り入れてみてください。不安な点や、「自社の環境でも導入・運用が可能なのか？」といった疑問があれば、どうぞお気軽にアクセルユニバースまでご相談ください。SREの導入や最適な運用体制づくりを、専門のチームが丁寧にサポートいたします。

1. はじめに
2. VPNに潜む"突破される前提"のリスク
3. ゼロトラストとは？ 「信用せず、常に検証する」
4. ゼロトラスト実現の3つの技術要素
5. 専用製品がなくても始められるゼロトラスト
6. ゼロトラストがもたらす運用の最適化
7. まとめ：ゼロトラストは「思想」であり、今すぐ始められる改革

1.はじめに

近年、リモートワークやクラウド活用が急速に進んだことで、企業のセキュリティモデルも大きな転換期を迎えています。従来の「社内ネットワーク＝安全」という前提のもと構築された境界型セキュリティは、もはや万能ではありません。
特に注目されているのが「ゼロトラスト」という新たなセキュリティモデルです。本記事では、VPNのリスクを再認識しつつ、ゼロトラストをいかに実践的かつ段階的に導入できるかについて、日々の運用に直結する視点で掘り下げていきます。

2.VPNに潜む"突破される前提"のリスク

VPNは、長らくテレワーク環境でのセキュリティ手段として広く使われてきました。しかし、VPN装置の脆弱性を突いた不正アクセスは、企業や公的機関でも後を絶ちません。
たとえば2020年、ある官公庁ではVPN経由で1年以上にわたり不正アクセスが行われ、内部システムが侵害されました。また、某大手ゲーム会社では、古いVPN機器が踏み台にされ社内ネットワークへの侵入を許してしまい、顧客情報流出という深刻なインシデントに発展しています。
VPNが破られると、まるで「社内に鍵のない裏口ができた」状態になり、攻撃者は内部のどこまでも自由に移動できてしまいます。この「一度突破されたら終わり」という構造こそが、VPN最大の弱点なのです。

3.ゼロトラストとは？ 「信用せず、常に検証する」

ゼロトラストは、「ネットワークの内側にいるから安全」という発想を根本から覆すモデルです。
その基本原則は非常にシンプルで、"Never Trust, Always Verify（決して信頼せず、常に検証する）" です。
ネットワークの内外を問わず、すべてのアクセスに対して認証・監視・制御を行うことで、内部での不正アクセスや"ラテラルムーブメント（横方向の攻撃の横展開）"を防ぐことができます。
重要なのは、「検証された結果としてのみアクセスが許可される」ことです。
これにより、「VPNで入ることができれば、すべての社内リソースに触れられる」といったリスクを根本から排除できます。

4.ゼロトラスト実現の3つの技術要素

ゼロトラストを実現するには、以下の3つの技術を柱として導入することが効果的です。

4-1. 多要素認証（MFA）

パスワードに加え、スマホ認証・生体認証・ワンタイムパスワード（OTP）などを組み合わせた認証方式です。
たとえパスワードが漏洩しても、他の要素がなければ突破できません。
特にVPNやクラウドアプリケーションへのアクセスには、最低限MFAを必須化すべきです。

4-2. マイクロセグメンテーション

ネットワークをアプリケーション単位・業務単位で細かく分割し、セグメント間の通信を厳格に制御します。万が一侵入されても攻撃の横展開を防げるため、ダメージを局所化できます。

4-3. 最小権限の原則（Least Privilege）

ユーザーやデバイスに業務上本当に必要なアクセス権のみを与える設計思想です。過剰な権限は脆弱性を生みます。これを徹底することで、万一の内部不正や誤操作にも強くなります。

5.専用製品がなくても始められるゼロトラスト

「ゼロトラスト＝高額なソリューション導入が必要」と思われがちですが、実際には既存環境で工夫しながら段階的に取り組むことが可能です。

• VPN＋MFAの導入から
  既存VPNや社内アプリケーションに、スマホ認証アプリ（Google Authenticator等）によるOTP認証を組み合わせることで、MFAをすぐに実装できます。

• ACL(Access Control List)やVLAN(Virtual Local Area Network)による論理分離
  ファイアウォールやスイッチの設定を見直し、部署・業務単位で通信を分離しましょう。マイクロセグメンテーションの簡易版として有効です。

• 権限棚卸しとIAMの活用
  特権アカウントの整理、不要な共有アカウントの廃止を徹底し、IAMを活用した最小権限の実現を図りましょう。あわせて、SSO基盤を整備することで、アクセス管理の一元化とユーザー利便性の両立も可能になります。

6.ゼロトラストがもたらす運用の最適化

ゼロトラストの導入は、単にセキュリティを強化するだけではありません。
セキュリティ運用そのものを「効率化」するという側面も持ち合わせています。

• アクセス制御の一元管理により、ポリシーの散在や重複を排除

• 統合ログ監視による可視性の向上と、インシデント対応の迅速化

• 同一ポリシー適用により、社内外でのルールのばらつきが解消

• 管理対象の削減により、IT部門の負担が軽減

これにより、人的ミスの削減、コスト圧縮、そしてIT担当者の工数確保につながります。

7.まとめ：ゼロトラストは「思想」であり、今すぐ始められる改革

ゼロトラストは、単なるセキュリティ製品ではなく「思想」と「戦略」です。まずは、VPN＋ID/パスワードの限界を正しく認識するところから始めましょう。
そしてMFAやネットワーク分離、権限整理といった今あるリソースでできることから一歩ずつ取り入れることで、リスクを大幅に減らし、運用も効率化できます。
「社内だから信頼する」という思い込みを捨て、「誰であっても、常に検証する」という新しい常識をチーム全体に浸透させていくことが、次世代のセキュリティ体制構築への第一歩となります。

1. はじめに
2. SREが向いているシステムの具体例
3. SREの効果を引き出すための技術的な要件
4. SREが効果を発揮する環境の整備
5. 導入事例：ある企業システムへのSRE適用例
6. まとめ

1.はじめに

クラウド環境の最適化を検討されている方が、SRE（Site Reliability Engineering）について情報収集をされる際、どのようなシステムが向いており、どんな条件下で最大の効果を発揮するのかを理解することは効果的です。本記事では、システムよりの具体例や技術的観点を交えて、「SREが適したシステム」と「効果を引き出すポイント」を詳しく解説します。

2.SREが向いているシステムの具体例

2-1.高可用性が必須な業務基幹システム

企業の中核を担う基幹システムは、業務の停止が直接的な損失や信頼の低下につながるため、SREの手法を取り入れることで信頼性を向上させられます。

・ERPシステム

販売管理、在庫管理、財務会計などを一元管理するERPシステムは、停止すると事業運営全体に影響を及ぼします。SREでは、システムダウンを未然に防ぐためのモニタリングや予測分析を導入し、ダウンタイムを最小化します。

・顧客管理システム（CRM）

クラウド型CRMシステムやオンプレミスCRMは、営業やカスタマーサポートの効率化に重要です。ここでのSLO設定（例: サーバ応答時間95%以内に100ms）やエラーバジェットの活用は、ユーザー満足度を高める鍵となります。

2-2. ミッションクリティカルなシステム

特に外部ユーザーや顧客が直接利用するシステムでは、障害がブランドや収益に影響を与えるため、SREの価値が大きく発揮されます。

・オンライン決済システム

決済処理では、1秒の遅延やエラーが信用損失につながります。SREでは、冗長構成や継続的な負荷テストを通じて高い可用性を確保します。

・物流システム

配送トラッキングや倉庫管理システムでは、リアルタイム性が重要です。分散システムの監視や障害発生時の迅速な切り替えをSREのアプローチで実現できます。

2-3. クラウドネイティブなシステム

クラウド技術を採用している場合、SREの手法は特に効果的です。

・コンテナオーケストレーション

Kubernetesなどのオーケストレーションツールを使用している場合、SREによる自動化が効果を発揮します。Podのスケールアウト/スケールインやフェイルオーバーの最適化がその一例です。

・サーバレスアーキテクチャ

サーバレス環境（例: AWS Lambda、Google Cloud Functions）では、オンデマンドでスケールする仕組みがあるため、SREによるモニタリングやパフォーマンス最適化が重要です。

3.SREの効果を引き出すための技術的な要件

3-1.明確なSLO/SLIの設定

SREの導入は、信頼性目標（SLO: Service Level Objective）が明確であるほど効果を発揮します。

SLO/SLI設定の具体例

・応答時間

Webアプリの応答時間を「95%のリクエストが200ms以下」と設定し、これをSLIで定量的にモニタリング。

・エラー率

APIリクエストの成功率を99.95%以上に保つ目標を設定し、これを監視ツールで追跡。

・ダウンタイム

月間許容ダウンタイムを「43.2分以内」（99.9%稼働）と設定し、エラーバジェットに基づいて適切な運用を実現。

3-2.モニタリングとアラートの強化

システムの信頼性を向上させるには、リアルタイムのモニタリングと自動アラートの整備が必要です。

使用可能なツール例

・インフラ監視

Prometheus、Zabbix、Datadogなどを活用し、CPU使用率やディスクI/Oを監視。

・アプリケーション監視

New RelicやAppDynamicsでトランザクション応答時間を可視化。

・ログ管理

ElasticsearchやSplunkでエラーログの集中管理と迅速な検索。

3-3. 自動化の推進

SREの効果を引き出すには、運用タスクを極力自動化することが重要です。

・自動デプロイ

CI/CDツール（例: Jenkins、GitLab CI）を使い、デプロイメントの迅速化とエラー削減を実現。

・リソース管理

Infrastructure as Code（例: Terraform、Ansible）でクラウドリソースの一元管理を行い、変更のトレーサビリティを確保。

・異常検知の自動化

AI/MLを活用した異常検知（例: DatadogのAnomaly Detection）で、潜在的な問題を早期に特定。

4. SREが効果を発揮する環境の整備

4-1.文化とプロセスの改革

SREは単なる技術ではなく、文化改革でもあります。システム企画部門が率先して以下を推進することが重要です。

・開発と運用の連携（DevOps）

システムダウンは顧客の信頼を損ない、ブランドイメージに悪影響を与えます。SREがシステムの安定稼働を支えることで、顧客離れのリスクを最小限に抑えられます。

・障害を許容する文化

「障害ゼロ」ではなく、エラーバジェットを活用し、許容範囲内での失敗を容認する仕組みを導入します。

4-2.段階的導入のすすめ

SREを全社的に導入する前に、次のような段階的なアプローチを取ることを推奨します。

・パイロットプロジェクトを設定

特に影響度の高いシステムや新規プロジェクトに限定してSREの実験的導入を行います。

・成功事例の展開

成果をもとに他のシステムへ展開し、組織全体での運用改善を目指します。

4-3.コストとROIの評価

SREの導入には初期投資が必要です。システム企画担当者としては、コストと効果のバランスを見極めることが大切です。

主なコスト要因:

・ツールライセンス

・エンジニアのトレーニング

・文化改革に必要な時間とリソース

投資効果の測定例

・障害発生時の復旧時間（MTTR: Mean Time to Recovery）の短縮。

・予定外のダウンタイムの減少による業務への影響削減。

・顧客満足度や信頼性向上による利益拡大。

5. 導入事例：ある企業システムへのSRE適用例

背景

ある製造業の企業では、クラウド上に顧客注文管理システムを構築していました。しかし、頻繁に発生するサーバ負荷問題とダウンタイムにより、顧客クレームが急増していました。

対応内容

1.SLOの定義

「95%のリクエストを1秒以内に処理する」という目標を設定。

2.監視とアラートの導入

Datadogでシステム全体をリアルタイムで監視し、CPUスパイク時にアラートを発生。

3.スケーリングの自動化

Kubernetesを利用して、トラフィック増加時にコンテナを自動スケール。

結果

・ダウンタイムが月間2時間から10分以下に減少。

・顧客満足度が15%向上。

・システム運用コストが10%削減。

6. まとめ

SREは特定の条件下で大きな効果を発揮するアプローチですが、すべてのシステムに適用すべきとは限りません。自社システムの特徴を分析し、SREの導入が適切かどうかを慎重に判断する必要があります。 リスクの少ないはじめ方として、パイロットプロジェクトを設定し、段階的にSREの導入を進めることで、リスクを抑えながら効果を最大化できます。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. エラーバジェット（Error Budget）：開発スピードと信頼性のバランス
3. ポストモーテム（Postmortem）：障害から学ぶ文化
4. トイル（Toil）：非効率な運用作業を削減する
5. まとめ

1.はじめに

日々進化するデジタルサービスの世界では、システムの安定性と開発スピードのバランスを取ることが求められます。しかし、現場のエンジニアの皆さまは、「システムの信頼性を確保しながら、どうやってスピーディに新機能をリリースできるのか？」というジレンマを抱えているのではないでしょうか。

そんな課題を解決するために生まれたのが「SRE（Site Reliability Engineering）」というアプローチです。本記事では、SREの実践に欠かせない3つのキーワード「エラーバジェット」「ポストモーテム」「トイル」を取り上げ、それぞれの意味と活用法をわかりやすく解説します。

開発チームと運用チームが円滑に連携し、より良いサービスを提供するためのヒントとして、ぜひご一読ください。

2.エラーバジェット(Error Budget)：開発スピードと信頼性のバランス

エラーバジェットとは？

エラーバジェットとは、GoogleのSREチームが導入した概念で、SLO（Service Level Objective）を基に「どの程度の障害が許容されるか」を数値化したものです（出典: O'Reilly『Site Reliability Engineering』）。この考え方により、開発チームは安全な範囲で新機能をリリースでき、信頼性とイノベーションのバランスを取ることが可能になります。

事例：エラーバジェットの活用によるデプロイ最適化

あるクラウドサービス企業では、「99.95%の可用性」をSLOとして設定し、それを超えない範囲で開発を進める仕組みを導入しました。この仕組み（エラーバジェット）を活用することで以下のような運用が可能になります。

• SLOが安全な範囲内では積極的に新機能をリリース
• 障害が発生し、エラーバジェットが枯渇するとデプロイを制限し品質向上に注力

このアプローチにより、開発チームと運用チームは共通の指標を持ち、デプロイのリスクを定量化しながらバランスの取れた開発サイクルを実現できます。

注意すべき点

エラーバジェットをうまく活用しないと、

• 障害が発生しているのに開発を優先してしまう
• 逆に慎重になりすぎて、開発スピードが落ちる

GoogleのSREチームは、「エラーバジェットは計画的に活用することが重要であり、完全になくすことを目標にするのではない」と述べています（出典: 『Site Reliability Engineering』）。つまり、信頼性を確保しつつ、エラーバジェットを最大限活用することで、開発のスピードと安定性の最適なバランスを維持することが求められます。

3.ポストモーテム(Postmortem) : 障害から学ぶ文化

ポストモーテムとは？

ポストモーテムは、システム障害発生後に実施する詳細な分析プロセスであり、GoogleのSREチームによって確立されました。このプロセスの目的は、「誰がミスをしたか」ではなく、「なぜミスが起こったのか」を理解し、再発防止のための対策を講じることです（出典: O'Reilly『Site Reliability Engineering』）。

事例：ポストモーテムの導入による障害対応の改善

あるeコマース企業では、過去に大規模なシステム障害を経験しました。この障害は、データベースの負荷増大と適切なスケーリング対策の不足が原因で発生しました。復旧には数時間を要し、多くのユーザーがアクセスできない状況となり、顧客満足度にも悪影響を及ぼしました。

この経験を踏まえ、同社ではポストモーテムの文化を導入し、以下の取り組みを実施しました。

• すべての重大な障害について詳細なレポートを作成
• 障害の根本原因を特定し、システム改善につなげる
• 関係者全員で共有し、今後の運用改善に活かす

この取り組みにより、同社の障害対応プロセスは大幅に向上し、類似の問題が発生する頻度が減少しました。また、ポストモーテムの実施を通じて、技術的な改善だけでなく、チーム全体の障害対応スキルの向上にもつながりました。

Googleは、ポストモーテムを「技術的な進化を加速させるための手段」と位置づけており、単なる問題報告ではなく、組織全体での学習と改善を目的とすることが重要だと強調しています。組織的にポストモーテムを実施し、継続的に改善を積み重ねることが、より信頼性の高いシステム運用につながるのです。

注意すべき点

ポストモーテムを有効に機能させるには、

• 「責任追及」ではなく「学びの場」として運用する
• 根本原因を明確にし、対策を具体的に定める

4.トイル(Toil) : 非効率な運用作業を削減する

トイルとは？

Googleの定義によると、トイルとは「手作業が多く、反復的で、自動化可能な運用作業」を指します。SREの基本理念のひとつに「トイルの削減」があり、エンジニアがより価値のある作業に集中できるようにすることが求められます（出典: O'Reilly『The Site Reliability Workbook』）。

事例：トイル削減による運用の効率化

あるWebサービス企業では、システム監視のアラート対応がエンジニアにとって大きな負担となっていました。頻繁に発生するアラートへの対応に多くの時間を取られ、本来注力すべき開発業務に影響が出ていたのです。

そこで、同社は以下の取り組みを実施しました。

• 繰り返し発生するアラートの自動対応スクリプトを作成
• ログ分析の自動化を導入し、手作業を削減
• 定期的なメンテナンス作業を自動化

これらの取り組みにより、エンジニアの手作業が大幅に削減され、より価値のある業務に集中できるようになりました。

この手法はGoogleのSREチームでも採用されており、Googleは「SREは運用作業の50%以上をトイルの削減に使うべき」と推奨しています。つまり、SREの役割は単なるシステム管理ではなく、運用の自動化と効率化を進めることで、信頼性の高いサービスを維持しながら開発のスピードを向上させることにあります。

注意すべき点

トイル削減を効果的に進めるには、

• 「単なる自動化」ではなく、本質的な業務改善を目指す
• 過剰な自動化によるシステムの複雑化を避ける
• SLO（サービスレベル目標）とのバランスを取る
• チーム全体での合意を形成する

5.まとめ

SREの現場では、「エラーバジェット」「ポストモーテム」「トイル」といった概念が、システムの安定性と開発の柔軟性を支える重要な要素として機能しています。

• エラーバジェットを活用することで、開発スピードと安定性のバランスを最適化
• ポストモーテムを実施することで、障害対応の質を向上させ、継続的な改善を促進
• トイルを削減することで、エンジニアの生産性を向上させ、より価値のある作業に集中可能に

これらの概念をうまく組み合わせることで、信頼性の高いシステム運用を実現し、開発スピードを維持することができます。アクセルユニバースでは、これらの手法を活用し、システムの安定性を最大化するソリューションを提供しています。ぜひ、貴社のSRE戦略にもご活用ください。

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

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の設定はサービスの特性によって異なり、それぞれの目的に応じた最適な指標を選ぶことが重要です。

6.まとめ

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

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

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

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

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

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

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

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

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で定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SREとは？
3. SREと従来のIT運用との違い
4. なぜSREが重要なのか？
5. SREの導入事例：Googleの成功事例
6. SREの課題と克服
7. 最後に

1.はじめに

「SRE」（Site Reliability Engineering) という言葉を聞いたことがあるでしょうか？ IT業界に携わっている方なら、特に耳にする機会が増えたかもしれません。 SRE（サイト信頼性エンジニアリング）は、今注目すべきトピックのひとつです。

SREはGoogleが提唱した概念で、ITインフラやシステム運用の信頼性向上と効率化を目指した革新的なアプローチです。本記事では、SREの基本的な考え方から、その導入が企業にどのようなメリットをもたらすのか、また、導入にあたってのポイントについてわかりやすく解説します。

2.SREとは？

SRE とは「Site Reliability Engineering」の略で、簡単に言うと、ソフトウェアエンジニアリングの手法を使って、システム運用の効率や信頼性を向上させるアプローチです。 SRE の概念は、Google で働くエンジニアのベン・トレイナー・スロス氏によって考案され、彼は「SREは本質的に、エンジニアが担当する運用である」と述べています。

従来の運用と比較すると、SREはエンジニアリング的なアプローチに強く依存しており、問題が発生した後に対応するのではなく、予防的な対策を行うことに重点を置いています。他の大規模なIT企業の実践によれば、SREはシステム全体の信頼性を向上させるだけでなく、同時に運用コストの削減や開発速度の向上にも最適とされています【1】。

3.SREと従来のIT運用の違い

SREと従来のIT運用の違いは、アプローチそのものにあります。従来のIT運用はシステムの安定稼働を重視し、システム障害が発生した際には迅速に対応する「反応型」の手法をとってきました。これに対して、SRE は、プロアクティブなアプローチを採用します。つまり、システム障害が発生する前に対策し、それを事前に防ぐことが重要視されます。

主な違い

①エラーバジェットの導入:SREでは、完璧な稼働率を目指すのではなく、許容可能な障害時間である「エラーバジェット」を設定し、信頼性と新機能の迅速なリリースのバランスを取ります。過度な可用性の追求は、開発効率や競争力の低下を招くリスクがあるとされています【2】。

②自動化の徹底: 人の手による運用はミスのリスクを増大させます。SRE では、自動化を徹底することで運用の効率性と安定性を向上させます。これにより、チームはより付加価値の高い業務に時間を割けるようになります。

4. なぜSREが重要なのか？

現在のビジネス環境では、ITシステムの安定性が企業の競争力に直結しています。特にクラウドベースのサービスやオンラインビジネスでは、わずかなダウンタイムが顧客離れや収益損失に直結する可能性があります。

SREを導入することで、システムの可用性やパフォーマンスを向上させ、同時にコスト削減を実現することが可能です。また、運用業務の自動化によりエンジニアの負担を軽減することで革新や新規開発に、より多くのリソースを割くことができるようになります。SREは、現代のビジネスにおいて不可欠な運用手法であり、企業の成長と競争力を支える重要な役割を果たします。以下に、SREの代表的な4つの手法を具体例と共に紹介します。

①サービスレベル目標（SLO）の設定

SREは、システムのパフォーマンスや可用性を測定するために、サービスレベル目標（SLO）を明確に定義することを重視します。SLOは「どの程度のサービスの可用性が必要か」 を定量的に示す指標であり、具体的な目標を設定することで、開発チームと運用チームの間の期待値を統一する役割を果たします【3】。

②モニタリングとアラート設定

SREでは、システム全体を継続的にモニタリングし、異常が発生した際には即座にアラートを発生する仕組みを構築します。これにより、障害が深刻化する前に予防的な対応が可能になります。また、適切に設計されたモニタリングシステムは、システム全体の普及性を大幅に向上させます。

③ポストモーテム分析

インシデントが発生した場合、SREは「ポストモーテム」と呼ばれる詳細な分析を行います。この分析は、問題の修正だけでなく、再発防止策の設計とチーム全体への共有を目的としています。この成長プロセスでは、ナレッジベースを構築し、フィードバックループを活用することで、継続的な改善につながっていきます。【4】。

④自動化の推進

SREの基本理念には、「人が行う繰り返し作業を可能な限り自動化する」という考えがあります。これにより、システム管理やメンテナンスにおける手動操作を極力抑え、エラーのリスクを軽減します。 自動化を推進することで、人的介入が減少し、運用コストの削減や運用効率の改善につながります。

5.SRE導入の例：Googleの成功事例

SREを導入したGoogleは、世界で最も大規模にSREを活用している企業の一つです。GmailやYouTube、Google検索といった主要なサービスを利用性が高い状態で提供するために、SREの手法に効果的にエラーバジェットを活用することで、新機能を迅速にリリースしながらも、信頼性を維持し続ける仕組みを実現しています。

このような取り組みは、概念的理論に留まらず、大規模で慎重な運用が求められる企業においても効果があることが証明されています。 さらに、Googleは他の企業がSREを導入する際のサポートも行っており、その成功例は多岐にわたります【5】。

6.SRE の課題とその克服

SREは多くの利点をもたらしますが、その導入にはいくつかの課題が伴います。特に、自動化の推進には初期投資や高度な技術力が必要です。システム管理の自動化ツールやモニタリングの仕組みを構築する為には、専門知識を持つ人材が不可欠であり、それに伴うトレーニングやスキルアップも企業全体で取り組む必要があります。また、これらの投資は短期的に目に見える成果が得られにくいため、長期的な視点を持つことが求められます。

さらに、SREの実装には企業文化の変革が必要不可欠です。SREの理念は、システムの信頼性向上を最優先にしつつも、新しいサービスや機能の迅速なリリースを目指すものです。しかし、これを達成するには、従来の「開発チーム vs 運用チーム」という対立構造を解消し、両者が密接に協力する体制を築かなければなりません。この文化的な変革は、リーダーシップやチーム全体の意識改革を伴うため、スムーズに進めることが難しい場合があります。

また、SREの導入では「信頼性」と「開発スピード」という相反する目標のバランスを取ることも課題の一つです。たとえば、開発チームが新機能の迅速なリリースを優先したい場合、運用チームは信頼性確保の観点から慎重なリリースを求めることがあります。このような状況を解決するために、Googleが提唱した「エラーバジェット」の概念が非常に有効です。エラーバジェットは、システムの許容範囲内での失敗を明確に定義することで、チーム間の合意形成を促し、両者の目標を両立させる仕組みとして機能します。

SREを成功させるためには、これらの課題に対して段階的かつ戦略的に取り組むことが重要です。たとえば、まずは小規模なプロジェクトでSREの手法を試し、その成果を全社的に展開することで、スムーズに導入を進めることができます。また、SREを導入する際には、経営層の理解と支援が欠かせません。必要なリソースを確保し、文化改革をスムーズに進めるためのサポートが求められます。

7.最後に

SREは、現代の複雑なITシステムを効率的に管理し、安定して稼働させるための革新的なアプローチです。Googleのような大規模な企業だけでなく、すべての企業にとってSREは信頼性向上や運用効率の改善に大きく貢献します。また、学術的な観点からも、SREの原則や実践は、システムの洞察性や可視性を向上させることが実証されています。

SREの導入は、システムの安定性を確保しながら、新しい機能やサービスをより迅速に提供できる体制を築くことが可能となり、顧客満足度や市場競争力の向上も期待できます。これからのビジネス競争において、SREを導入することは競争力を高めるための重要なステップとなるでしょう。皆様の組織でも、ぜひSREの導入を検討してみてはいかがでしょうか？

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SREとSEOの重要な関連性
3. 技術的アプローチ：SREによるSEO改善の戦略
4. まとめ

1.はじめに

最近、Googleが「Core Web Vitals」を検索アルゴリズムの重要な指標として組み込んだことで、サイトのパフォーマンスや信頼性などSEOに与える影響が一層注目されるようになりました。これまで、マーケティング部としてSEO対策といえばキーワードやコンテンツの最適化が主な取り組みでしたが、それだけでは十分ではない時代に突入しています。

弊社のSRE担当のエンジニアと話している際、サイトのパフォーマンスや安定性を改善することが検索エンジンからの評価に直結するため、SRE（Site Reliability Engineering）の考え方がSEOにも有効であるという事実を知りました。SREが目指す可用性やスケーラビリティの向上といった取り組みが、単にシステムの信頼性を高めるだけでなく、検索結果における順位向上やユーザー体験の改善にもつながるというものです。

この気づきは、私たちマーケティング部にとっても新鮮なものでした。技術的な施策とマーケティング施策を連携させることで、ビジネスの成果をさらに押し上げる可能性が広がります。

この記事では、SREのプラクティスをSEOにどう活用できるのかをテーマに、エンジニア視点を取り入れながら掘り下げていきます。技術チームがいかに関わってSEOやサイト運用の効率化を進められるのか、新たな発見が得られる内容をお届けします。ぜひ最後までご覧ください。

2.SREとSEOの重要な関連性

2-1. SREがSEOに与える影響

SREは、システムの「信頼性」と「パフォーマンスの最適化」を追求する役割を持ちますが、これらはSEOにおいても重要な要素と深く関係しています。非常に安定していることは、ユーザーエクスペリエンスだけでなく、検索エンジンからの評価にも直結するのです。 以下のポイントが特に注目すべき要素です：

1.稼働率の維持

Webサイトがダウンしている時間は、検索エンジンがそのサイトをクロールできません。これが頻繁に起こると、検索エンジンはそのサイトを信頼できなくなるとみなし、ランキングを低下させる可能性があります。障害の早期検知や復旧を迅速化することで、稼働率が高い段階で維持することができます。

2.エラーレートの削減

404エラーや5xxエラーが増加すると、Googleはそのサイトを「ユーザー体験を損なうサイト」と判断します。これにより検索エンジンの評価が低下し、SEOランキングに悪影響を及ぼします。 SREでは、ログの監視やエラー率の自動アラートを活用し、エラーの発生を迅速に把握する仕組みが完了しています。これにより、問題を回避し、検索エンジンやユーザーに信頼されるサイト運営が可能になります。

3. ページ速度の最適化

ページ速度は、現代のSEOにおける最重要指標の一つです。 ページの読み込みが遅いと、ユーザーが逃げるだけでなく、Googleのランキングでも不利になります。 ちなみにGoogleが重視するCore Web Vitals（ LCP、FID、CLS）では、速度や応答性が評価の中心となっています。SREのパフォーマンス監視や最適化手法を活用すれば、キャッシュの効率化やCDN（コンテンツ配信ネットワーク）の導入によって、ページ速度を大幅に向上させることが可能です。

2-2. SEO目標に合ったSLO（Service Level Objective:サービスレベル目標）の設定

SREの観点から、SEOに合わせたSLOを設計することは、技術チームとマーケティングチームの連携を深める重要なステップです。具体的には以下のような目標を設定します。

・稼働率目標: 99.95%以上の稼働率を維持します。

・ページ速度目標: 95%のリクエストで2秒以下の応答を実現します。

・エラー率目標: HTTP 404や500系エラーを0.1%未満に抑えます。

これらのSLOを基に、SEOパフォーマンスに直結するKPI（Key Performance Indicator）を設定することで、定量的な改善計画を立てる事が可能になります。

3.技術的アプローチ: SREによるSEO改善の戦略

以下は、技術チームが日々の業務に取り入れられる具体的な取り組み内容です。SREの視点を活かしてSEOパフォーマンスを向上させるための実践例を挙げます。

3-1. Webパフォーマンスの強化

キャッシュの活用と最適化

・長期キャッシュの実装: JavaScriptやCSSファイルを適切にキャッシュすることで、再ダウンロードを減少させます。

・動的コンテンツのキャッシュ戦略: ユーザーセッションに依存するページも、キャッシュ可能な構造に最適化します。

CDNの導入とエッジ最適化

・グローバルユーザーに対する応答速度を向上させるため、CDN（Content Delivery Network）を活用します。

・エッジキャッシュを設定し、ユーザーに最も近い場所からリソースを提供することで応答時間を短縮します。

3-2. 安定したデプロイメントの確立

継続的デリバリー（CI/CD）のベストプラクティス

・ロールバックプロセスの自動化: リリース後の問題に迅速に対応できるよう、即時ロールバックが可能な仕組みを構築します。

・カナリアリリースの実施: 小規模なトラフィックに対して新しい変更をテストすることで、トラブル発生時の影響を最小限に抑えます。

モニタリングの自動化

・アラートポリシーの設計: パフォーマンスやエラーレートの急激な変化を検知するアラートを設定し、問題を迅速に把握できる仕組みを整えます。

・リアルユーザー監視（RUM）: 実際のユーザーのアクセスデータを収集分析し、潜在的な課題やボトルネックを特定します。

3-3. Core Web Vitalsの完全最適化

・LCP（Largest Contentful Paint）: サーバーの応答時間を短縮し、主要コンテンツを迅速にレンダリングします。

・FID（First Input Delay）: JavaScriptの実行を細分化し、インタラクティブ性を向上させます。

・CLS（Cumulative Layout Shift）: 画像や広告などに定義済みのコンテナサイズを設定することで、レイアウトのズレを防ぎ、視覚的な安定性を確保します。

4.まとめ

SREを活用することで、Webサイトの品質とパフォーマンスを技術的に高めるだけでなく、SEOにも大きな効果を生み出すことができます。 ページ速度の最適化といったところは、技術チームが注力すべき重要なポイントです。特に、Googleが重視するCore Web Vitalsへの対応を進めるには、CI/CDの導入、キャッシュの最適化、CDNの活用といった具体的なアプローチが効果的です。これらの取り組みは、システムの安定性を向上させるだけでなく、検索エンジンの評価向上にもつながります。マーケティング部としても、技術チームと連携してSREのプラクティスを日常業務に取り入れることで、ユーザー体験を向上させながら、サイトのビジネス価値を最大化することが重要だと感じています。Webサイトは単なる技術的な基盤ではなく、ビジネス成長の基礎です。技術とマーケティングの両方の視点を融合させれば、さらに競争力の高いWebサイト運営によるビジネス成長が実現できると考えます。

「SEOに強い技術基盤を構築したい」「サイトのパフォーマンスを向上させたい」という企業様がございましたら、アクセルユニバースにぜひお気軽にご相談ください！

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SREとは？
3. SREのメリット
4. SREのデメリットと対策
5. まとめ

1.はじめに

現代のITシステムにおいて、システムの信頼性は企業にとって最も重要な要素の一つです。サービスの停止や障害は、顧客満足度の低下や収益損失に直結するため、システムを安定して稼働させることが求められています。しかし、システムの複雑化や運用業務の負担増加により、信頼性を確保するのは容易ではありません。 この課題を解決するために注目されているのが、SRE（Site Reliability Engineering） です。SREはGoogleが提唱した運用手法で、システムの信頼性を高め、サービス停止や障害を防ぐことを基本的な目的としています。 本記事では、SREの具体的なメリットと導入の重要性について解説します。

2.SREとは？

SRE（Site Reliability Engineering）は、システム運用にソフトウェアエンジニアリングの手法を取り入れ、信頼性と効率性を向上させるアプローチです。特に、サービスの停止や障害を防ぎながら、安定したシステム運用を実現することに重点を置いています。

SREの基本的な目的

・システムの可用性と信頼性を確保

・サービスの停止や障害の未然防止

・運用タスクの自動化による効率化

・継続的な運用改善

SREの主な要素

・SLI（Service Level Indicator）：サービスの状態を数値で示す指標（例：稼働率や応答時間）。

・SLO（Service Level Objective）：SLIに基づく目標値（例：稼働率99.9%以上）。

・エラーバジェット：サービスの停止許容範囲を定め、デプロイや改善のバランスを取る仕組み。

3.SREのメリット

SREを導入することで、企業はシステム運用をより信頼性が高く効率的なものへと進化させることができます。以下に、SREの主なメリットを解説します。

3-1.システムの信頼性向上

SREの最大の目的は、システムの信頼性を高めることです。SLIやSLOを設定し、システムの状態を定量的に管理することで、障害発生を未然に防ぎます。

効果

サービス停止のリスクを大幅に低減し、ユーザー体験を向上させます。

3-2. 障害対応の迅速化

障害が発生した場合、SREでは標準化された対応プロセスや自動復旧スクリプトを用いて、迅速な復旧を実現します。また、障害後には「ポストモーテム（事後検証）」を実施し、再発防止策を徹底します。

効果

ダウンタイムを最小限に抑え、システム安定性を維持します。

3-3. 運用自動化による効率化

SREでは、繰り返し発生する運用タスク（例：ログ監視や障害対応）を自動化します。これにより、エンジニアは戦略的な業務に集中できるようになります。

効果

人的ミスの削減と運用効率が向上します。

3-4.継続的な運用改善

障害の原因分析や運用データのフィードバックを基に、運用プロセスを継続的に改善します。これにより、システムの信頼性がさらに向上します。

効果

長期的な安定稼働と効率的な運用体制が確立できます。

4. SREのデメリットと対策

SREには多くのメリットがありますが、導入に際しては以下のような課題もあります。

4-1.導入に時間とコストがかかる

SREの導入には、SLI/SLOの設定や運用体制の見直し、自動化ツールの構築などが必要で、初期段階でコストや時間がかかります。

対策

・小規模な試験運用（PoC）から始め、段階的に導入を進める。

・外部の専門家やパートナー企業のサポートを活用する。

4-2.高度なスキルが求められる

SREを実践するには、運用自動化やデータ解析の知識が必要です。チームメンバーのスキルアップが求められる場面もあります。

対策

・専門トレーニングや教育プログラムを実施する。

・SREの専門家を採用または育成する。

4-3.運用形骸化のリスク

SREの導入後、運用が形骸化し、改善サイクルが停滞するリスクがあります。特に、ポストモーテム（事後検証）が適切に行われないと、運用効果が低下する可能性があります。

対策

・定期的な運用レビューと改善サイクルをプロジェクト化する。

・SREの責任者を明確にし、継続的な改善を推進する体制を構築する。

5. まとめ

SRE（Site Reliability Engineering）は、システムの信頼性向上を軸に、運用効率化とサービス停止の未然防止を実現する強力なアプローチです。

SRE導入の主なメリットは、①システムの信頼性向上、②障害対応の迅速化、③運用自動化による効率化、④継続的な運用改善の4点でした。

一方で、導入時には時間やコスト、スキル不足の課題が伴う場合があります。しかし、適切な計画と体制構築、外部の専門家のサポートを活用することで、これらのデメリットを解決できます。弊社にはこれらの課題を解決しながらSREの導入を成功に導いた多くの実績があります。

<お客様からいただいたお言葉>

・依頼していなかったら、AWSセキュリティ改善活動は、後回し・先送りになりスタートすらできていなかった

・技術力の高さから得られる安心感を感じる、無い知見と技術力でを補っていただける

・漠然とした課題がプロジェクト化でき、柔軟な体制で進めることができるようになった

SRE導入は確かに初期段階で工夫が必要ですが、適切なパートナーがいることでスムーズに進めることができます。弊社は、お客様のシステム環境や課題に合わせた柔軟な体制を構築し、SRE導入を支援いたします。

SRE導入に興味をお持ちでしたら、ぜひお気軽にご相談ください。私たちと一緒に、信頼性の高いシステム運用を実現しましょう。

無料ご相談会はこちらから

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. システムの健康診断を超えて：SREの価値とは？
3. SREがもたらす「攻め」の価値：エラーバジェットの考え方
4. 顧客体験向上に直結するSREの役割
5. 総合診療としてのSRE：ビジネスとシステムの架け橋
6. SREの未来：システム運用を超えた価値創造
7. まとめ

1.はじめに

SRE（Site Reliability Engineering）は、単なるシステム運用の効率化や信頼性向上に留まりません。ビジネスの要求に応えつつ、顧客体験を向上させるためには何が必要かを常に考え、実践する多面的なアプローチが求められます。その役割は、まるでシステムの「総合診療医」ともいえる存在です。

2.システムの健康診断を超えて：SREの価値とは？

一般的に、SREの取り組みはシステムの安定稼働や障害対応、自動化、セキュリティ強化など、技術的な課題にフォーカスされがちです。しかし、それだけでは十分ではありません。システムが正常に稼働することはもちろん重要ですが、その先にある「ビジネスへの貢献」や「顧客体験の向上」を視野に入れることで、真の価値を発揮します。

たとえば、大規模なシステム障害が発生すれば、単に復旧作業を行うだけでなく、その障害がどのように顧客体験やビジネス成果に影響を与えたかを分析し、再発防止策に反映させる必要があります。SREは、技術のスペシャリストであると同時に、ビジネス価値を創出する「戦略的パートナー」としての役割を果たすべき存在です。

3.SREがもたらす「攻め」の価値：エラーバジェットの考え方

SREの中心的な考え方のひとつに「エラーバジェット」があります。エラーバジェットは、許容できるシステム停止時間を数値化したもので、信頼性と新機能開発のバランスを取る指標として機能します。

エラーバジェットの仕組み

1.定義

例えば、月間稼働率を99.9%に設定した場合、43.2分の停止が許容されます。この範囲内であれば、新機能開発や改善作業を積極的に進められます。

2.活用例

エラーバジェットが十分に残っている場合、リスクを取って新しい機能をリリースし、顧客価値を高めることが可能です。 逆に、エラーバジェットを超えた場合は、安定性を最優先し、リリースを一時停止するなど、システムの改善に専念します。

この仕組みにより、SREは「攻め」と「守り」の両立を図りながら、システムの成長と安定性をバランス良く保つことができます。

4. 顧客体験向上に直結するSREの役割

SREの最終的な目標は、エンドユーザーの体験を向上させることにあります。単にシステムを止めないだけでなく、次のような形で顧客満足度や企業の成長に貢献します。

4-1.コスト削減と再投資

SREの取り組みによって運用コストを削減できれば、その余剰資金を新しいサービスや機能開発に再投資できます。例えば、効率化したインフラ運用費用を新商品の開発や顧客サポート体制の強化に回すことで、顧客体験を向上させることが可能です。

4-2.ブランドイメージの保護

システムダウンは顧客の信頼を損ない、ブランドイメージに悪影響を与えます。SREがシステムの安定稼働を支えることで、顧客離れのリスクを最小限に抑えられます。

4-3.障害の影響を最小化

障害が発生した場合、迅速な復旧や影響範囲の限定化を実現することで、顧客が感じる不便を最小限に抑えます。これにより、障害発生時でも顧客満足度を一定に保つことが可能です。

5. 総合診療としてのSRE：ビジネスとシステムの架け橋

SREは、「システム」と「ビジネス」の両方を理解し、両者を結びつける役割を担っています。この視点で見たとき、SREには次のような特徴があります。

5-1.システムとビジネスを包括的に見る能力

SREは、技術的な側面だけでなく、ビジネス目標や顧客ニーズを深く理解し、それに即した運用改善や新機能の提案を行います。たとえば、売上に直結する重要なシステムの稼働を優先的に保証する一方、リスクが低い部分では柔軟性を持たせるといった判断が求められます。

5-2.分断された組織の架け橋

多くの企業では、システム部門とビジネス部門が分断され、協力がスムーズに進まないことがあります。SREは、その間に立ち、技術的視点とビジネス視点をつなぐことで、組織全体の効率を高めます。

6.SREの未来：システム運用を超えた価値創造

SREは、システム運用の専門家から、ビジネス成長を支えるパートナーへと進化しつつあります。今後のSREには、次のような期待が寄せられています。

1.予測可能な運用

AIや機械学習を活用し、障害を未然に防ぐ運用体制の構築。

2.顧客中心の戦略

顧客満足度を重視した新しいKPI（Key Performance Indicator）の設定と管理。

3.ビジネス貢献の明確化

運用改善がビジネス成果に与える影響を定量化し、企業全体の価値を可視化。

7. まとめ：SREは「攻め」と「守り」の要

SREは、単なるシステム運用の枠を超えた多面的な取り組みを通じて、企業全体の成長を支えるエンジンとなります。顧客体験の向上、コスト削減、ブランド保護といった効果を最大化するには、SREを「総合診療」として捉え、ビジネスと技術のバランスを常に意識する必要があります。

今後もSREは進化を続け、企業にとって欠かせない存在となっていくでしょう。技術とビジネスを結びつけるこの新しい役割を積極的に取り入れることが、未来の成功を左右する鍵となるはずです。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. クラウド運用の課題
3. 解決方法
4. クラウド運用の改善事例
5. まとめ

1.はじめに

クラウドコンピューティングの普及により、多くの企業がオンプレミスのインフラからクラウド環境へと移行しています。しかし、そのメリットを享受する一方で、クラウド運用に伴う新たな課題も浮上しています。特に、コスト管理やセキュリティ、パフォーマンス最適化といった運用面の複雑さが企業にとって大きな問題となっています。本記事では、クラウド運用における主な課題と、それに対する効果的な解決方法を紹介します。

2. クラウド運用の課題

コスト管理の難しさ

クラウドのメリットの一つに、利用したリソースに応じた課金モデルがあります。しかし、これがかえってコストの見えにくさを引き起こす要因にもなります。特に複数のクラウドサービスを併用するマルチクラウド環境では、どのリソースがどれだけのコストを消費しているのかを把握するのが難しく、意図せぬコスト増加が発生しがちです。

クラウドリソースの無駄遣い

クラウドリソースの無駄遣いとは、使用されていないにもかかわらず停止されていないリソースが増加し、結果的にコストや管理負担が膨らむ状態を指します。これは特に大規模な開発環境や、サービス運用を長期間にわたって行う企業でよく見られる問題です。

セキュリティリスクの増加

クラウド環境に移行することで、セキュリティの責任共有モデルを理解し、オンプレミスとは異なるセキュリティ要件を管理しなければなりません。特に、クラウド上でのデータ保護、アクセス制御、コンプライアンス遵守など、セキュリティリスクに対する意識と対応が重要です。

最適なパフォーマンス維持が難しい

クラウドサービスは多くのメリットを提供しますが、パフォーマンス最適化が難しい場合があります。クラウドサービスプロバイダーが提供するインフラに依存するため、ネットワーク遅延や、キャパシティの問題が発生することがあります。また、アプリケーションの規模が大きくなると、システム全体のパフォーマンス管理が複雑化します。

3.解決方法

クラウドコスト管理ツールの活用

クラウドコストを最適に管理するためには、コスト管理ツールの導入が効果的です。AWSのAWS Cost ExplorerやMicrosoft AzureのAzure Cost Management、Google CloudのCost Management Dashboardなどのツールを活用することで、リアルタイムのコスト分析や予算設定、コストの異常な増加を監視できます。これにより、無駄なリソースの特定や、効率的なコスト配分が実現します。

ゼロトラストアーキテクチャの導入

セキュリティリスクを軽減するためには、ゼロトラストモデルの導入が有効です。ゼロトラストアーキテクチャでは、内部外部のネットワークを問わず、すべてのアクセスを検証し、信頼できる通信のみを許可します。また、IAM（Identity and Access Management）ツールを使用し、ユーザーやデバイスのアクセス権を厳密に管理することで、セキュリティを強化できます。クラウドサービスに対して多要素認証（MFA）を導入することも有効な方法です。

リソース起動の自動化とガバナンス

クラウドリソースの無駄遣いを防ぐためには、自動化とガバナンスの強化が必要です。クラウドプロバイダーが提供するツール（例えば、AWSのAWS LambdaやAuto Scaling）を活用し、使用していないリソースを自動的に削除またはスケールダウンさせる仕組みを構築しましょう。加えて、運用ポリシーやリソースの使用に関するガバナンスルールを明確に定義し、それに従うことが重要です。

パフォーマンスモニタリングの強化

クラウド上でのパフォーマンスを最適化するためには、モニタリングを強化する必要があります。クラウドサービスプロバイダーの提供するモニタリングツール（AWSのCloudWatch、AzureのAzure Monitorなど）を活用し、システム全体のパフォーマンスをリアルタイムで監視しましょう。これにより、ボトルネックを迅速に特定し、パフォーマンス向上に向けた調整を行うことができます。

インフラ改善・構築の効率化

クラウド環境を効率的に管理し、柔軟にスケールするためには、Infrastructure as Code (IaC)のアプローチが役立ちます。IaCを利用することで、インフラをコードとして管理し、再利用可能なテンプレート化による迅速なデプロイやスケーリングが可能となります。これにより、手動設定によるエラーを減らし、一貫した運用が実現できます。

4.クラウド運用の改善事例

大手Eコマース企業の事例

ある大手Eコマース企業は、急速な成長に伴い、クラウド環境の運用コストが大幅に増加していました。同社は、マルチクラウド戦略を採用していたため、リソースが適切に活用されていないことが大きな課題となっていました。

この企業は、AWS Cost Explorerを活用し、使用されていないリソースやコスト増加の要因を特定しました。その結果、未使用のリソースを削減し、クラウド環境全体でのコスト削減に成功しました。また、Infrastructure as Codeを導入することで、インフラの管理とデプロイ作業を自動化し、運用効率も向上しました。

中堅企業のセキュリティ強化事例

ある中堅企業では、従業員が多様なデバイスからクラウドにアクセスすることが増えたため、セキュリティリスクが懸念されていました。同社はゼロトラストセキュリティモデルを導入し、すべてのアクセスに対して厳格な認証を行う仕組みを構築しました。また、IAMツールと多要素認証を導入することで、セキュリティリスクを軽減しました。これにより安全なクラウド運用が可能になりました。

5.まとめ

クラウド運用には多くのメリットがある一方で、コスト管理やセキュリティ、パフォーマンス最適化など、解決すべき課題も数多く存在します。しかし、適切なツールや戦略を導入することで、これらの課題を効果的に解決し、クラウド環境を最大限に活用することが可能です。企業がクラウドの利点を活かしながら、運用を最適化するためには、継続的な改善と適切な管理体制の構築が不可欠です。

クラウド運用に関するご相談や最適化についての詳しい情報をお求めの場合は、ぜひ私たちにご連絡ください。クラウド導入から運用の最適化まで、貴社のニーズに合わせた最善のソリューションを提案いたします。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. 導入
2. SREにおける視点の違い
3. SREを外部に委託する利点
4. SRE外部委託の課題とコストの問題
5. 自社の一員として動いてくれるSREパートナーを選ぶ
6. SREを社内で運用するか外部に委託するかの選択
7. まとめ

SRE（Site Reliability Engineering）の外部委託における利点と課題について、システム運用の効率化とコスト管理の観点で適切な委託先の選び方を解説します。

1. 導入

SREは、システムの安定運用と信頼性向上を実現するために不可欠な役割を果たします。特に、システムの障害発生リスクを最小限に抑え、サービスの継続的な提供を保証することが重要です。しかし、企業がこのSREの役割をどのように担うかという選択は、システムの規模や企業のリソース状況に大きく左右されます。SREを社内で構築し運用するか、それとも外部に委託するかは、企業がシステム運用において直面する大きな課題の一つです。本記事では、SREを外部に委託することの利点と課題、そして成功に導くための適切な委託先の選び方について詳しく説明します。

2. SREにおける視点の違い

SREの基本的な目的は、システムの信頼性を高め、サービスの停止や障害を防ぐことです。これには、システムの自動化、継続的なモニタリング、障害対応体制の強化などが含まれます。技術的には、インフラの冗長化や障害時のフェイルオーバー、負荷分散の最適化などを実施することがSREの重要な業務です。

しかし、ビジネス視点でのSREの役割は、単にシステムを安定的に動作させるだけでは不十分です。企業が成長し、ビジネスの要求が高度になるにつれて、SREの目的は、システムの安定運用をベースに、エンドユーザー体験の向上や業務効率の改善を目指すものに変わります。つまり、技術的なパフォーマンスの最適化だけでなく、最終的にビジネス全体にどう貢献できるかがSREの評価指標となります。SREは、システム運用にとどまらず、企業の戦略的なビジネス目標に向けて、顧客体験を改善し、コスト削減や運用効率化を通じて、企業全体の成長を支える役割も担っているのです。

3. SREを外部に委託する利点

企業がSREを外部に委託する理由はさまざまですが、その主な利点は以下の通りです。

3-1. 専門的な知識と経験の活用

外部のSREチームは、さまざまな業界やプロジェクトで培った専門的な知識と経験を持っています。彼らは、特に大規模で複雑なシステムや、マイクロサービスアーキテクチャを採用している企業において、その知識を活かして迅速かつ効果的に問題解決を図ります。たとえば、オンプレミスからクラウドへの移行や、クラウドネイティブな環境での運用効率化など、社内チームでは得難い専門的なスキルを提供することができます。

3-2. 柔軟な人的リソースの活用

外部委託によって、企業はリソースを柔軟に活用することが可能です。社内でSREチームを固定費として維持するよりも、外部のSREリソースを必要に応じて変動費として活用できるため、コスト管理がしやすくなります。たとえば、繁忙期や新しいプロジェクトの立ち上げ時に追加リソースが必要になった場合、外部のSREチームを一時的に増強することで、短期間での対応が可能となります。

3-3. 高い対応力とスピード

外部のSREチームは、複数のプロジェクトを経験しているため、問題解決や障害対応のスピードに優れています。例えば、突発的なシステム障害が発生した場合、経験豊富な外部のSREチームは迅速に原因を特定し、最適な解決策を実行します。また、24時間365日の対応が求められるような運用環境において、外部委託はスピーディな対応と高い信頼性を提供します。

4. SRE外部委託の課題とコストの問題

しかし、SREの外部委託にはいくつかの課題があります。最も大きな課題はコストの問題です。外部のSREチームを活用する場合、特に長期間にわたるプロジェクトでは、社内でSREを運用する場合と比較してコストが高くなることがあります。契約形態やサービス内容によっては、予算を超過するリスクもあります。そのため、企業はコスト対効果を十分に考慮し、運用効率を維持しつつ、費用を適切に管理する必要があります。

また、外部のSREチームが企業のビジネス戦略や目標を理解しているかどうかも重要なポイントです。単なる技術的な問題解決だけでなく、企業全体の目標にどのように貢献できるかを考える外部チームと連携することが不可欠です。これを実現するには、定期的なコミュニケーションと、目標に対する明確な期待値の設定が必要です。

5. 自社の一員として動いてくれるSREパートナーを選ぶ

SREを外部に委託する際には、単に技術力や価格だけで選ぶのではなく、「自社の一員として動いてくれる」パートナーを選ぶことが重要です。従来のシステム開発においては、顧客からの依頼に基づいて開発会社が対応するという形が一般的でしたが、SREはそれとは異なるアプローチが求められます。

SREの外部委託においては、外部のSREチームが単に顧客の要求に応じるだけでなく、プロアクティブに課題を発掘し、解決策を提案することが重要です。外部チームが率先してシステムの潜在的な問題を見つけ、顧客が気づいていないリスクや改善点を提案することで、システムの安定性やパフォーマンスを向上させることができます。これが、SREを外部に委託する際の真の価値です。

企業は、単なる技術的なサポートを超えて、ビジネス全体に貢献できる外部パートナーを選ぶことが、長期的な成功への鍵となります。このようなパートナーを見つけることで、企業はシステム運用の安定性を確保しつつ、エンドユーザー体験の向上やビジネス価値の最大化を実現できます。

6. SREを社内で運用するか外部に委託するかの選択

SREを社内で運用するか、外部に委託するかの判断は、企業の規模や戦略によって異なります。社内に専任のSREチームを構築することで、特定のプロジェクトや業務に深く関与し、企業のビジネス目標に沿った運用が可能となります。しかし、社内リソースの制約や、システムの複雑化による負荷増加を考慮すると、外部に委託する選択肢も検討する価値があります。

特に、新規サービスの導入や、大規模なシステム更新を控えている場合、外部のSREチームを活用することで、短期間での立ち上げや運用を成功させることができます。企業は、自社の現状と将来的なニーズを踏まえ、最適なSRE戦略を選択することが重要です。

当社では、上記の間をとって、お客様社内へのSREチームの立ち上げを実施することもできます。具体的には、数名のお客様SREチームに経験豊富な当社メンバーも数名参画し、チームの習熟度を高めながら、お客様SREチームがひとり立ちすることを支援しています。

7. まとめ

SREを外部に委託することは、システムの信頼性向上や運用効率化において多くのメリットをもたらします。外部委託による柔軟なリソース活用や、豊富な経験を持つチームによる迅速な対応は、特に大規模なシステム運用において有効です。しかし、外部委託にはコストや適切なパートナー選びといった課題も伴います。

SREの外部委託を成功させるためには、単なる技術的なサポートに留まらず、企業のビジネス目標やエンドユーザー体験にまで貢献できる外部パートナーを選ぶことが不可欠です。SREを自社の成長戦略にどのように組み込むかを明確にし、信頼できるパートナーと連携することで、システム運用の最適化と企業の成長を両立させることが可能です。

SREの外部委託に関するご相談や詳細については、ぜひお問い合わせください。貴社のニーズに合わせた最適なソリューションを提供し、システム運用の成功を支援します。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

目次

1. 背景
2. コスト削減のための分析
3. 解決策
4. 結果

背景

Amazon RDS（Relational Database Service）は、多くの企業で利用されるマネージド型データベースサービスです。高可用性や自動バックアップなどの機能を備えており、運用管理の負担を軽減しますが、使い方によってはコストが膨らみ、企業のIT予算を圧迫する原因となります。
当社でもRDSのコスト最適化に取り組み、その結果、利用コストを最大で50％削減することに成功しました。

RDSコスト削減のために改善できるポイントは以下の通りです。
1. 使用していないリソースが長期間稼働している。
2. データベースインスタンスのサイズが適切でないため、リソースが過剰に割り当てられている。
3. ストレージやバックアップが最適化されていない。
4. オンデマンド料金が高く、コストが予測しづらい。
今回は、これらの問題に対処するために行った原因調査と解決策について具体的に解説し、どのようにコスト削減を実現したかを紹介します。

コスト削減のための分析

まずは、AWS Cost Explorerを使用してRDSのコストを詳細に分析しました。

RDSのコスト構成要素

1．インスタンスの稼働料金：データベースインスタンスのサイズに応じて、時間ごとに発生。
2．ストレージ料金：データベースのストレージ容量に基づいて発生。
3．バックアップ料金：自動バックアップやスナップショットに対するストレージ料金。
4．データ転送料金：データベースから外部に出るデータの転送料。

不必要なコストの原因

1．過剰なインスタンスサイズ：使用しているインスタンスサイズが過大であり、実際のトラフィックに比べてリソースが過剰に割り当てられていた。
2．ストレージの最適化不足：必要以上に高パフォーマンスなストレージタイプを使用していた。
3．リザーブドインスタンスの未活用：オンデマンドインスタンスを利用しており、リザーブドインスタンスのディスカウントを活用していなかった。

解決策

それぞれの問題を解決するため、以下の施策を実行しました。

1. インスタンスサイズの適正化

アプローチ

RDSインスタンスのサイズを、実際のトラフィックやパフォーマンス要件に基づいて見直しました。
例えば、CPU使用率やメモリ使用量がインスタンスのスペックに比べて著しく低い場合、インスタンスを小さいものに変更することで、コストを削減できます。
以下の表のように、m5.largeからt3.mediumに変更すると、月額200USD以上のコスト削減が期待できます。

ポイント

オンデマンドインスタンスは、利用時間に応じて料金が発生するため、インスタンスの稼働状況に応じたリサイズを行うことで、効率的にコストを削減できます。

2. ストレージタイプの最適化

アプローチ

RDSはストレージの種類として、汎用SSD（gp2）、プロビジョンドIOPS（io1）、マグネティックなどがあります。高パフォーマンスなio1を利用していたものの、実際にはそこまでの性能が必要なかったため、汎用SSD（gp2）に変更することでストレージコストを削減しました。

500GB使う場合のそれぞれのストレージタイプでのコストは以下のため、月額252USDの削減が期待できます。

ポイント

ストレージタイプを最適化することで、コストを大幅に削減できます。特に、I/O性能が必要ない場合は、汎用SSD（gp2）を利用するとよいです。

3. リザーブドインスタンスの活用

アプローチ

オンデマンド料金が高く、長期的にRDSを使用することが分かっている場合、リザーブドインスタンスを購入することで、コストを大幅に削減できます。
リザーブドインスタンスは1年または3年のコミットメントを前提に割引が適用されるため、オンデマンドインスタンスに比べて最大で40％のコスト削減が期待できます。

db.t3.mediumの場合、リザーブドインスタンスの活用有無でのコストは以下です。リザードインスタンス1年利用だけでも、月額34USD程度のコスト削減が期待できます。

ポイント

長期的な利用が予想されるRDSインスタンスに対しては、リザーブドインスタンスを活用することで、コストの削減が可能です。
オンデマンド料金と比較して、割引率が高いため、特に3年契約を検討する価値があります。

4. 自動バックアップとスナップショットの最適化

アプローチ

自動バックアップやスナップショットは、定期的に実行されますが、不要なバックアップやスナップショットを削除することで、ストレージコストを削減しました。
バックアップの保持期間を短縮することや、不要なスナップショットを定期的に削除する運用を導入しました

コスト計算

バックアップストレージ: 0.095USD/GB/月
50GBの不要なスナップショットを削除する場合: 50GB × 0.095USD = 月額4.75USDの削減

結果

これらの最適化アプローチにより、RDSのコストを全体で約50％削減することができました。
特に、インスタンスサイズの見直しとストレージタイプの最適化が大きな影響を与え、リザーブドインスタンスの活用で長期的なコスト削減効果をさらに高めました。

総合的なコスト削減効果（月額）

• インスタンスサイズの適正化による削減: 200USD
  

• ストレージタイプの最適化による削減: 252USD
  

• リザーブドインスタンスの活用による削減: 34USD
  

• バックアップとスナップショットの最適化による削減: 4.75USD
  

• 合計削減額: 490.75USD
  

Amazon RDSのコスト削減は、インスタンスの見直しやストレージの最適化、長期的な利用を考慮したリザーブドインスタンスの活用など、いくつかの簡単な手順で達成可能です。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

はじめに

AWSのアカウント管理を実施するにあたり「Well-Architected Framework」への考慮は必要不可欠です！ 私たちAWSユーザは、AWS Organizationsを利用したマルチアカウント戦略の実践を、AWSからベストプラクティスとして推奨されています。 今回は、AWS Organizationsを利用したマルチアカウント戦略の実践により、AWSアカウント管理でよくある課題を解決する方法をいくつかご紹介いたします。

目次

• AWSアカウント管理でよくある課題
• AWS Organizationsによるマルチアカウント戦略
  • AWS Organizationsのみで実現
  • AWS Organizations + AWSマネージドサービスの組み合わせで実現
• まとめ

AWSアカウント管理でよくある課題

まずはじめに、

• アカウント管理
• セキュリティ
• コスト

の3つの観点から、AWSアカウントを利用する上でお客様からよく伺う課題を見ていきます。

これらの課題の多くは、AWSアカウントの 個別管理 に起因しています。 では、上記課題の解決策を、AWS Organizationsを利用したマルチアカウント戦略の観点から確認したいと思います。

AWS Organizationsによるマルチアカウント戦略

まずは、AWS Organizationsの機能について確認します。

AWS Organizationsとは、AWSアカウントを統合・管理・制御するためのAWSサービスであり、追加料金は不要です。1つのAWSアカウントを管理アカウントとして指定することで組織を作成します。その組織へのAWSアカウントの作成または追加により、階層構造を実現します。この階層構造により、システムやプロジェクト毎にAWSアカウントを分けて管理することが可能です。これが、AWS Organizationsを利用したマルチアカウント戦略です。さらには、AWS OrganizationsとAWSマネージドサービスを組み合わせることにより、一層ハイレベルなAWSアカウントの管理を実現します。

以下では、AWS Organizationsを利用した具体的な課題の解決方法を見ていきます。

AWS Organizationsのみで実現

AWS Organizations + AWSマネージドサービスの組み合わせで実現

このようにAWS Organizationsにおけるマルチアカウント戦略を最大限活用することで、

• アカウント一元管理 : 複数AWSアカウントの統合管理
• セキュリティ強化 : 漏れのない完全なるセキュリティポリシー
• コスト追跡 : AWS組織全体でのコスト最適化

これらを実現し、AWSアカウントを管理する上での多くの課題を網羅的に解決することができます！

まとめ

ここまで「AWS Organizationsによるマルチアカウント戦略」について見てきました。 ご自身が利用されているAWSアカウントの管理状況と比較していただき、改善点など見つかりましたでしょうか？ AWS Organizationsやその他のAWSマネージドサービスとの組み合わせを採用し、AWSのベストプラクティスに沿ったAWSアカウント管理を実践しましょう！ご精読いただきありがとうございます。

はじめに

今回は、アクセルユニバースのインフラエンジニアがAWSアカウントのコスト削減を実施する際に利用しているチェックリストをご紹介いたします。

AWSコスト削減チェックリスト

私たちアクセルユニバースのAWSコスト削減チェックリストは

• チェック対象リソース/サービス
• コスト削減観点(状態)
• 手段

の3つの項目から構成されています。 私たちインフラエンジニアはこのチェックリストを元に「クラウド支出の最適化(FinOps)」におけるコストの最適化を実践しております。

こんなお悩みはありませんか？

• クラウド化は実施したが想定よりコストがかかっている...
• コスト削減可能性を感じているが多忙で調査に手が回らない...

そのお悩みアクセルユニバースが解決します！

アクセルユニバースでは、素早くお手頃、でも根本的にAWSコストの最適化を実現します。 AWSコスト削減サービスをお求めの方はこちらまで

ご挨拶

AWS全冠エンジニアの小澤です。
今年の目標はテニスで初中級の草トーナメントに優勝することです。よろしくお願いいたします。

本記事の目的

本記事では、生成AIでVOC分析を行うことで得られた知見を共有したいと思います。

昨今、生成AIの登場など機械学習の進歩は目覚ましいものがあります。一方、足元では自社データの利活用が進まず、世の中のトレンドと乖離していくことに課題感を持たれている方も多いかと思います。また、ガートナーの調査(2024年1月)によると、日本企業でデータ活用の成果を得られている企業は3％にとどまっているようです。

特に顧客の声(Voice Of Customer)は、大量の非構造化データで、内容も多様かつ複雑なため特に分析が難しい領域です。また、効果的に分析できれば実りの大きい領域でもあります。

早速やってみた

VOC分析のデモ対象としてCSVファイルを用意しました。こちらは「都内に展開する高級ハンバーガーチェーンのカスタマーフォームのデータ」という設定で、生成AIで顧客の声を99件作成しています。

上記のCSVファイルを生成AIで前処理して、BIツールに取り込むことで下記デモのように手軽にVOC分析が始められます。

今回のやってみたで得られたポイントは以下の３点です。

• テキストマイニングの専門的知見がなくても大量データを分析してインサイトを創出できる
• GPT-4で一つの顧客の声から複数のカテゴリと感情分析を抽出できる (GPT-3.5だと物足りない)
• どのようにカテゴリを組成するかが分析の肝であり、その目的に応じてカテゴリの再構築が必要

それでは、具体的な手順に入っていきます。

1.データの前処理

デモデータに含まれるお客様申し出内容を生成AIでカテゴライズ、感情分析、要約します。
今回はカテゴリ一覧も生成AIで用意させました。最終的に利用したカテゴライズ用プロンプトは記事の最後に参考情報として記載しています。

当初、前処理にはGPT-3.5を利用しましたが、カテゴライズの精度に少し物足りなさを感じたためGPT-4を利用するように変更しました。
GPT-4を利用して、一つの顧客の声から複数のカテゴリ、異なる感情分析を生成できたのは興味深い結果でした。人間だと一つカテゴライズしたら手を抜いてしまいがちとなるので、GPT-4と同程度の精度で大量のデータを以下のようにカテゴライズするのは難しいと思います。

INPUT

今日、プレミアムバーガー赤坂店でランチセットを利用しました。バーガーのサイズは満足できるものでしたが、サイドメニューのポテトが少なく感じました。
また、ドリンクの種類がもっと多ければ嬉しいです。価格に見合った量と質を期待していたので、少しガッカリしました。
しかし、店員さんの対応はとても良く、快適なランチタイムを過ごせました。今後、ランチセットの内容を見直し、コストパフォーマンスを高めることをお勧めします。

OUTPUT

[
  {
    "大カテゴリ": "店舗",
    "カテゴリ": "サービス",
    "サブカテゴリ": "スタッフの態度",
    "感情分析": "Positive",
    "要約": "店員の対応が良く、快適なランチタイムを提供"
  },
  {
    "大カテゴリ": "商品企画",
    "カテゴリ": "メニュー開発",
    "サブカテゴリ": "その他",
    "感情分析": "Negative",
    "要約": "サイドメニューの量とドリンクの種類に不満"
  },
  {
    "大カテゴリ": "商品企画",
    "カテゴリ": "フィードバック管理",
    "サブカテゴリ": "商品改善",
    "感情分析": "Neutral",
    "要約": "ランチセットの内容とコストパフォーマンスの改善を提案"
  }
]

それでは、これらの分析結果をBIツール(QuickSight)に取り込んで、どのようなインサイトが得られるか見ていきます。

2.全体把握

まずは円グラフとヒートマップで顧客の声をざっくり視覚化します。

ヒートマップでは店舗のネガティブな声が目を引きますが、これは全体に占める「店舗」への声、ネガティブな声の割合を考慮すると自然な結果です。ここは更に細かく分析をしていく必要がありそうです。
一方で、「商品企画」への声はポジティブである比率が高く、商品力に優れたハンバーガーチェーン店であることが伺えます。

今回はエリアマネージャーになったつもりで店舗にフォーカスして分析を進めていきます。

3.店舗にフォーカスした分析

引き続き、店舗の声について全体把握するために円グラフとヒートマップでざっくり視覚化します。

店舗へのネガティブな声の割合は、全体と比較すると少し高めであることが分かります。
ヒートマップを見ると、「待ち時間」や「スタッフの態度」に課題がありそうです。一方で、「雰囲気」はポジティブな声が多く、店舗の強みとなっていることが分かります

店舗別のヒートマップを見ると、「プレミアムバーガー新宿」に多くのネガティブな声、「プレミアムバーガー赤坂」にポジティブな声が集まっていることが分かります。これらの情報を元に分析を深掘りしていきましょう

4.分析の深掘り

詳細分析はピボットテーブルを利用して行い、店舗横串で改善すべき項目を確認していきます。

ここで、エリアマネージャーとしての私は店舗改善の指標として強みとなっている「雰囲気」に着目しました。
顧客からポジティブな評価を集めている赤坂店などはマネージャーとしての経験とも合致するところがあり、その要素を分析して他店舗に横展開する施策はイメージが湧きました。

一方で、クレーム件数の多い「待ち時間」はモバイルオーダーなどのシステム起因であったり、時間帯やプロモーションのピーク性など要因が絡まり合っており、クイックウィンが難しいことは自明だったので、今回はスコープから除外することにしました。

またVOC分析では「その他」を洗うことも重要です。ここには認知できていなかった課題が埋もれています。

店舗改善で更にインサイトを得るためには、ユニフォームが「その他」に組み込まれないようカテゴリの再構築が必要でしょう。

やってみた振り返り

顧客の声という非構造化データをカテゴライズ・感情分析し、そこからインサイトを創出するデモをやってみました。

しかし、本当に価値があるのはインサイトから仮説を構築し、検証するための分析プロセスだと感じました。そのためには、カテゴリの再構築を繰り返すことで次々とインサイトを創出するインタラクティブな分析が必要です。
今回の例で言えば、店舗の雰囲気に「スタッフの態度」が大きく影響している可能性でないか？などの仮説が立ちますし、それに合わせてカテゴリの再構築が必要でしょう。

そして現場を分かっている人ほど、これらの顧客の声から精度の高い仮説を立てられると思います。また改善施策を実施後、適切に可視化されたダッシュボードでデータの時系列をトラックし、効果測定を行うことも重要です。

そのためにはデータ分析の専門性を持たなくても、担当者がインタラクティブにデータ分析と視覚化を行えるシステムが必要です。そのようなシステムは生成AIをデータ分析に組み込むことで、自然言語を介して実現出来ると思います。

AWSのマネージドサービス活用

AWSのマネージドサービスを組み合わせることで、VOC分析をセキュアにスモールスタートできます。

Amazon Bedrockはエンタープライズ向けの生成AIでセキュアに利用できますし、QuickSight には自然言語でBIを構築する新機能も発表されています。今後もAWSで生成AIを活用するマネージドサービスは増えていくと思いますので、私としてもAWS全冠にあぐらをかかず最新技術をキャッチアップしていく所存です。

当社について

当社は顧客中心主義を掲げ、お客様にとって本当に価値があるソリューションの提供を目指しています。
本記事に関連するところで言えば、システム企画からピュアな機械学習によるデータ分析、クラウドコールセンターの構築や問合せ情報管理システムの開発までワンストップで提供できます。

私自身はSRE(サイト信頼性エンジニアリング)を主戦場に、お客様が抱えるITの課題抽出から企画、実行まで行っています。最近では「サイト」ではなく、「顧客」に信頼性の対象を置くCREという概念も出てきており、今後は顧客の声をKPIに設定する取り組みもチャレンジしていきたいと考えています。

もし当社に興味を持たれましたら、こちらのお問い合わせフォームよりご連絡いただければ幸いです。

参考（カテゴライズで利用したプロンプト）

下記の問い合わせ内容をカテゴライズ表に厳密に従って大カテゴリ、カテゴリ、サブカテゴリに分類してください。
また該当カテゴリのトピックサマリも３０字以上50字未満で記載ください。

## 問い合わせ内容
{{お客様お申出内容}}

## 出力形式
JSONで該当するカテゴリを1〜3個出力してください
[
  {
    "大カテゴリ": "",
    "カテゴリ": "",
    "サブカテゴリ": "",
    "感情分析": "",  // Negative or Neutral or Positive
    "要約": ""
  }
]

## カテゴライズ表
大カテゴリ,カテゴリ,サブカテゴリ,サンプルシナリオ
店舗,サービス,待ち時間,注文から30分以上待たされた
店舗,サービス,スタッフの態度,スタッフが無愛想
店舗,サービス,アレルギー対応,アレルギー情報の不足
店舗,サービス,注文間違い,ヴィーガンバーガーの注文間違い
店舗,サービス,その他,該当なし
店舗,環境,雰囲気,店内のインテリアが洗練されている
店舗,環境,清潔さ,店内の清掃が行き届いていない
店舗,環境,騒音レベル,店内がうるさくて食事が楽しめない
店舗,環境,照明,店内の照明が暗すぎる
店舗,環境,その他,該当なし
店舗,設備,アクセシビリティ,車椅子でのアクセスが困難
店舗,設備,座席の快適さ,座席が狭くて快適でない
店舗,設備,Wi-Fiの利用,Wi-Fiが遅くて使い物にならない
店舗,衛生管理,手洗い設備,手洗い設備が不足している
店舗,衛生管理,清掃の頻度,トイレの清掃が不十分
店舗,衛生管理,その他,該当なし
店舗,顧客体験,訪問のしやすさ,店舗までのアクセスが困難
店舗,顧客体験,情報提供,メニュー情報が不明瞭
店舗,顧客体験,特別な要求への対応,特別な食事要求に対応できない
店舗,顧客体験,その他,該当なし
店舗,その他,該当なし,該当なし
商品企画,メニュー開発,新商品の提案,新商品のアイデアが不足
商品企画,メニュー開発,健康志向のオプション,健康志向メニューが少ない
商品企画,メニュー開発,季節限定メニュー,季節限定メニューが魅力的でない
商品企画,メニュー開発,その他,該当なし
商品企画,フィードバック管理,顧客の意見集約,顧客の意見が反映されない
商品企画,フィードバック管理,商品改善,商品の改善が見られない
商品企画,フィードバック管理,トレンド分析,最新トレンドの分析不足
商品企画,フィードバック管理,その他,該当なし
商品企画,その他,該当なし,該当なし
モバイルオーダー,システムパフォーマンス,アプリの安定性,アプリがクラッシュする
モバイルオーダー,システムパフォーマンス,注文処理速度,オンライン注文の遅延
モバイルオーダー,システムパフォーマンス,ユーザーインターフェース,アプリの操作が複雑
モバイルオーダー,システムパフォーマンス,その他,該当なし
モバイルオーダー,機能性,カスタマイズオプション,カスタマイズオプションが限られている
モバイルオーダー,機能性,アレルギー情報,アレルギー情報が不足している
モバイルオーダー,機能性,ナビゲーション,アプリのナビゲーションがわかりにくい
モバイルオーダー,機能性,その他,該当なし
モバイルオーダー,その他,該当なし,該当なし
オンラインストア,商品在庫,限定商品の在庫状況,限定グッズがすぐに売り切れる
オンラインストア,商品在庫,商品情報の更新,商品情報が最新でない
オンラインストア,商品在庫,その他,該当なし
オンラインストア,注文システム,システムの使いやすさ,オンライン注文がしにくい
オンラインストア,注文システム,注文の処理速度,オンライン注文が処理されない
オンラインストア,注文システム,注文の正確性,オンライン注文が間違っている
オンラインストア,注文システム,その他,該当なし
オンラインストア,その他,該当なし,該当なし
ポイントシステム,利用体験,ポイント加算の明確さ,ポイントが予想より少ない
ポイントシステム,利用体験,利用方法,ポイントの利用方法が分かりにくい
ポイントシステム,利用体験,利用可能商品,ポイントで交換できる商品が少ない
オンラインストア,利用体験,その他,該当なし
ポイントシステム,システム性能,システムの安定性,ポイントシステムのエラー
ポイントシステム,システム性能,アクセスの容易さ,ポイントシステムへのアクセスが難しい
ポイントシステム,システム性能,情報の透明性,ポイントの計算が不透明
ポイントシステム,システム性能,その他,該当なし
ポイントシステム,その他,該当なし
プロモーション,宣伝,SNSでの告知,SNSでのプロモーションが見つからない
プロモーション,宣伝,メールマーケティング,プロモーションメールが届かない
プロモーション,宣伝,店内告知,店内でのプロモーション告知が目立たない
プロモーション,宣伝,その他,該当なし
プロモーション,オファー,限定メニュー,限定メニューの魅力
プロモーション,オファー,その他,該当なし
プロモーション,その他,該当なし,該当なし

## 特記事項
カテゴライズ表に厳密に従ってください。存在しない項目を生成しないでください。
大カテゴリ、カテゴリ、サブカテゴリを異なる組み合わせにしないでください
そしてJSONのみ出力してください

目次

• 挨拶
• CI/CD導入の背景
• 前提
• プロジェクト構成
• ディレクトリ構成
• .circleci/config.yml 全体の流れ
• 試行錯誤したところ
• 今後の展開

挨拶

CircleCIでdocker-composeを使ってテストからAWS ECSへのデプロイまでを自動化してみたので紹介します。

CI/CD導入の背景

参加しているプロジェクトではアジャイルを取り入れ、毎月リリースするようになりました。
毎月リリースがあるということは、それだけ機能改修、追加、削除があるということで、その分テストが必要になります。リリースの作業も毎月やってきます。時間がかかります。

そこで、CircleCIを導入しテスト工程とデプロイ工程、さらには2工程間の処理を自動化することで、工数を減らしつつ品質担保を実現しました。

前提

AWS ECSのサービス/クラスターの作成や、CircleCIの登録とSet up projectまで済んでいます。
AUCではVCSにGitHubを、CI/CDツールとしてCircleCIを利用しています。どちらもAUCが構築したAWS上で動いています。
技術ブログ『AWSを利用した弊社の開発環境』

プロジェクト構成

プロジェクトは、AWS ECS上に構築され、開発はDockerを用いてRuby on Railsで行っています。テストはRSpecで行っています。

ディレクトリ構成

.
├── .circleci
│   └── config.yml
├── Dockerfile
├── Dockerfile.ecs
├── docker-compose.ecs.yml
├── docker-compose.rspec.yml
├── docker-compose.yml
├── ecs-service.json
├── spec

docker-composeファイルは、開発用、CirlceCIのRSpec実行ジョブ用、CirlceCIのAWS デプロイジョブ用の3つに分けています。それぞれで無駄なイメージをプルしたり、不要なキャッシュを設けたりするのを省くためです。Dockerfileも同じように不要な設定を省く目的で2つに分けています。

全体の流れを紹介するために.circleci/config.ymlとデプロイに使うdocker-compose.ecs.ymlを載せています。docker-compose.rspec.ymlやDockerfileは長くなるので割愛しました。

.circleci/config.yml

version: 2.1

jobs:
  rspec:
    docker:
      - image: cimg/python:3.11.5
    working_directory: ~/repo
    steps:
      - checkout
      - setup_remote_docker
      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "Gemfile.lock" }}
            - v1-dependencies-
      - run:
          name: Create Docker Network
          command: docker network create --subnet=172.19.0.0/16 itid_group
      - run:
          name: Start Docker Compose services
          command: docker-compose -f docker-compose.rspec.yml up --build -d
      - run:
          name: Create DB
          command: docker exec -it app_web bundle exec rake db:create RAILS_ENV=test
      - run:
          name: Run RSpec tests
          command: |
            docker exec -it app_web bundle exec rspec
            docker-compose down
      - save_cache:
          paths:
            - ./vendor/bundle
          key: v1-dependencies-{{ checksum "Gemfile.lock" }}

  build_image:
    docker:
      - image: cimg/python:3.11.5
    steps:
      - checkout
      - setup_remote_docker
      - run:
          name: Install AWS CLI
          command: |
            sudo pip install awscli
      - run:
          name: Build image
          command: |
            $(aws ecr get-login --no-include-email --region ap-northeast-1)
            docker-compose -f docker-compose.ecs.yml build --build-arg RAILS_MASTER_KEY=${RAILS_MASTER_KEY} --build-arg RAILS_ENV=production
            docker tag project_web ${ECR_DOMAIN}/app-web:$CIRCLE_SHA1
            docker tag project_web ${ECR_DOMAIN}/app-web:latest
      - run:
          name: Push Docker Image
          command: |
            docker push ${ECR_DOMAIN}/app-web:$CIRCLE_SHA1
            docker push ${ECR_DOMAIN}/app-web:latest
  deploy:
    docker:
      - image: cimg/python:3.11.5
    steps:
      - run:
          name: Install AWS CLI
          command: |
            sudo pip install awscli
      - run:
          name: Migration
          command: |
            aws ecs run-task \
              --region ap-northeast-1 \
              --launch-type FARGATE \
              --network-configuration "awsvpcConfiguration={subnets=["subnet-*****************", "subnet-*****************", "subnet-*****************", "subnet-*****************"],securityGroups=["********************"],assignPublicIp=ENABLED}" \
              --cluster app-ecs-cluster --task-definition app-migrate
      - run:
          name: Deploy
          command: |
            aws ecs update-service --cluster app-ecs-cluster --service app-service --task-definition app --force-new-deployment

workflows:
  version: 2
  test:
    jobs:
      - rspec
      - build_image:
          filters:
            branches:
              only: ecs_deploy
      - deploy:
          requires:
            - build_image
          filters:
            branches:
              only: ecs_deploy

docker-compose.ecs.yml

version: "3.9"
services:
  web: &web
    container_name: 'app_web'
    build:
      context : .
      dockerfile: Dockerfile.ecs
    command: bash -c "yarn install &&
             rm -f /app/tmp/pids/server.pid &&
             freshclam &&
             service clamav-daemon start &&
             bundle exec rails s -p 3000 -b '0.0.0.0'"
    ports:
      - "3000:3000"
    tty: true
    stdin_open: true
    environment:
      REDIS_URL: 'redis://localhost:6379/1'
    networks:
      - app_group
      - default
  # 毎回ビルドする必要がないため、別個ECRにpushした
  # redis:
  #   container_name: 'app_redis'
  #   image: redis:7-alpine
  #   ports:
  #     - "6379:6379"
  #   command: redis-server --appendonly yes
  sidekiq:
    <<: *web
    container_name: 'app_sidekiq'
    ports:
      - "5001:3000"
    command: bundle exec sidekiq -C config/sidekiq.yml

.circleci/config.yml 全体の流れ

1. プロジェクトメンバーがGitHubにpushすると、CircleCIがトリガーされ、rspec jobのRSpecテストが実行されます。

2. RSpecのテストが通ったらレビューを行います（人力）。これにパスしたら開発環境へのデプロイ用ブランチ ecs_deployにmergeします（人力）。

3. ここで再度CircleCIが実行され、今度はrspec job実行後、build_image jobでAWS ECRにイメージが保存されます。

4. イメージの保存が完了すると、最後にdeploy jobが実行され、ECRに保存されたイメージを利用してAWS ECSにアプリケーションがデプロイされます。

build image jobのPush Docker Imageで$CIRCLESHA1とlatest2つのタグをつけたイメージをpushしています。
latestタグがついたイメージをdeploy jobで使用しています。$CIRCLESHA1タグをつけるのはバージョン管理のためです。
CircleCI 定義済み環境変数

deploy jobでは、まずapp-web:latestイメージを用いてDBのマイグレーションを行っています。
その後、Deployで同じapp-web:latestイメージを用いてapp-deployタスクを実行し、app-ecs-clusterクラスターにアプリケーションをデプロイします。

試行錯誤したところ

docker-compose を利用したビルド

CircleCI導入当時、.circleci/configは直にrubyのイメージをプルして直に環境構築することを想定していましたが、開発環境はもともとDockerで構築していたため、CircleCIもdocker-composeを利用して構築することにしました。
管理するコードを減らし、ローカルとCircleCI環境の環境差がrspecテストに影響しないようにできました。

docker:
      - image: cimg/ruby:3.1.2-browsers
    steps:
      - checkout

# ↓各jobのイメージはdocker-composeをインストール済みの仮想マシンを使用するよう変更

docker:
      - image: cimg/python:3.11.5
    steps:
      - checkout
      # -setup_remote_dockerでリモート Docker環境をアクティブ化。これでdockerコマンドが使えるようになる
      - setup_remote_docker

RedisのECRイメージだけ別でpushした

ECRのイメージは本当はapp-web1つにまとめられると良かったのですが、docker-compose.ymlを利用したビルドではRedisはRedis単独のイメージとしてpushされておりapp-webイメージ、redisイメージの2つができていました。それに気づかずデプロイを進め、Redisが参照できないとエラーが出ていました。

生成されたredisイメージを使うことも考えましたが、プロジェクトで使用しているRedisは現在バージョン7で固定しており、毎回のイメージビルドは不要です。
そこで、最初に別個ECRへredis-7イメージをpushしてそれを使用するようにしました。
docker-compose.ecs.ymlでredisの部分をコメントアウトしているのはそのためです。Redisのバージョンアップがある際にはまたpushする予定です。

rspec jobのDB接続がうまくいかない

DBセットアップ前にmigrateしようとしてエラーが発生したため、migrateとseedはrspecコマンド実行時にspec/rails_helper.rb内で行われるようにしました。

エラーメッセージ

rails aborted!
ActiveRecord::NoDatabaseError: We could not find your database: app_test. Which can be found in the database configuration file located at config/database.yml.

spec/rails_helper.rb

# 一部抜粋
RSpec.configure do |config|
  config.before(:suite) do
    Rails.application.load_tasks
    # migrateにはridgepole gemを使用
    Rake.application['ridgepole:apply'].invoke
    Rails.application.load_seed
  end
end

rspec jobのsubdomain付きURLへのアクセスでNet::ReadTimeoutエラー

ローカルでのテストはパスしていたのですが、CircleCI上ではsubdomain付きURLへのアクセス箇所で失敗していました。
プロジェクトではRSpecのテストでWEBブラウザを操作するためにSeleniumを使用しています。
調べてみると、Webdriverが内部的にいろいろなドライバーと通信するのにHTTPを使用していて、その通信にはRubyの標準ライブラリであるNet::HTTPが使われているようです。このNet::HTTPのデフォルトタイムアウトが60秒になっていてそこでひっかかっているようでした。
Selenium ドキュメント

Failures:

1) 管理画面にログインする
Failure/Error: visit login_path

Net::ReadTimeout:
Net::ReadTimeout with #

Seleniumのドキュメントの通りread_timeoutを設定するとうまく通りました。

spec/support/capybara.rb

Capybara.register_driver :remote_chrome do |app|
  # 一部抜粋
  client = Selenium::WebDriver::Remote::Http::Default.new
  client.read_timeout = 240
end

今後の展開

CI/CDを導入してテストからデプロイまで一気通貫で行えるようになりました。今後の展開として以下に上げる点を改善していきたいです。

latestタグ運用の廃止

deploy jobのDeploy、Migrationでlatestタグのついたイメージを使用しているのは、コミットハッシュのタグを使う運用に変更したいです。
具体的には、ECSのタスク定義でlatestタグのついたイメージを使用するようにしていますが、毎回コミットハッシュのタグ付きのイメージを使用するようタスク定義を書き換えるようにします。
そうすることで、障害発生時の切り戻しが迅速に行えるようになるのでベストプラクティスのようです。

デプロイの前に手動承認のひと手間を加える

CircleCIには、[Approval (承認)] ボタンがクリックされるまでジョブの実行を待つ手動承認の機能があります。
現在のconfigファイルではcommitしたらすぐにテストからデプロイまで走ってしまいますが、手動承認を実装してデプロイは実行者の承認のもと行うようにしたいです。

マイグレーション前のDBバックアップ

プロジェクトではDBにRDSを使用しています。マイグレーションの前にスナップショットを撮るようにして、バックアップするようにしたいです。

Net::ReadTimeoutエラーの解消方法

今回はread_timeout = 240として解消しましたが、240秒はちょっと長すぎるので、根本原因を探り改善したいです。

Image by Freepik

目次

• 背景
• 原因究明
• 解決策
• 結果

背景

 AUCでは、SRE活動の一環として、AWSコストの適正化を行っています。
（技術ブログ『SRE：コスト抑制のための異常値検知機構の実装』）
コスト適正化における課題は、大きく分けて下記の4つです。

①コストは月末にチェックしており、月中でコストが急激に上昇した場合発見が遅れてしまう。
② 不要なリソースが放置されていたり、新たなリリースによって生じたコストを確認していない。
③ AWSが提供するベストプラクティスによるコスト適正化が行われていない。
④ コストに対する意識が薄い。

今回のブログでは、『③ AWSが提供するベストプラクティスによるコスト適正化が行われていない。』により発生していたコスト増加について行った、原因調査〜コスト削減までを記録します。

 対象となるサービスはNAT Gatewayです。直近1年間のコスト推移調査の結果、NAT Gatewayのコストが1年で約64%増加していることを検知しました。
NAT Gatewayの料金は時間単位料金とデータ処理料金の2つあります。

• 時間単位料金：NAT Gatewayの利用時間に対して0.062USD/時 ※
  
• データ処理料金：NAT Gatewayで処理されたデータ量に対して0.062USD/GB ※
  ※東京リージョンの場合（Amazon VPCの料金より）
  
  

NAT Gateway作成後、時間単位料金は一定のため、データ処理料金が増加しているであろうことが予測できます。
NAT Gatewayの通信先を特定し、NAT Gatewayを通す必要がないデータを通してしまっていないか調査します。

原因調査

 VPCフローログを使用し、取得したログをCloudWatch Logs Insightで分析することでNAT Gatewayの通信先を特定します。

1. IAMポリシーの作成

 VPCフローログを作成する前に、VPCフローログがCloudWatch LogsにアクセスできるようにIAMポリシーを作成します。 「IAM＞ポリシー＞ポリシーを作成」を選択し、JSONに下記コードを記載、任意のポリシー名を付けてポリシーを作成します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}   

2. IAMロールの作成

 1で作成したIAMポリシーをVPCフローログにアタッチするためのロールを作成します。
「IAM＞ロール＞ロールを作成」を選択し、信頼されたエンティティタイプで『カスタム信頼ポリシー』を選択して下記コードを記載します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
} 

許可ポリシーは1で作成したポリシーを選択し、任意のロール名を付けてロールを作成します。

3. CloudWatch Logs ロググループの作成

 VPCフローログのログを入れるためのロググループを作成します。
「CloudWatch＞ロググループ＞ロググループを作成」を選択し、任意のロググループ名を付けてロググループを作成します。

4. VPCフローログの作成

 VPCフローログを作成するための準備が整いましたので、いよいよフローログを作成します。
VPCフローログ自体には料金は発生しませんが、CloudWatch Logs側でデータ取り込み料金が発生するため、今回のように一時的な利用の場合は通信先特定後にVPCフローログを削除することをおすすめします。

調査対象のNAT GatewayのVPCにチェックを入れ、アクションで『フローログを作成』を選択します。

任意のフローログ名を入力し、それぞれ下記を選択します。

• 送信先：CloudWatch Logsに送信
• 送信先ロググループ：3で作成したロググループ
• IAMロール：2で作成したロール

5. ログの分析

 取得したログを分析してNAT Gatewayの通信先を特定します。今回は1週間分のログを分析します。
「CloudWatch＞ログのインサイト」で4で作成したロググループを選択し、それぞれ下記クエリを実行します。

実行クエリ

①NAT Gatewayからインターネットへの通信

• 送信元IP/CIDR
  • 'X.X.X.X'：対象NAT Gatewayのプライマリプライベート IPv4 アドレスを指定
• 除外する宛先IP/CIDR
  • 'Y.Y.Y.Y/YY'：対象VPCのCIDRを除外。複数CIDRがある場合はand not isIpv4InSubnet〜を繋げる
    
    

filter (srcAddr like 'X.X.X.X') and not isIpv4InSubnet(dstAddr, 'Y.Y.Y.Y/YY')
| stats sum(bytes) as bytesTransferred by srcAddr, dstAddr
| sort bytesTransferred desc

②インターネットからNAT Gatewayへの通信

• 宛先IP/CIDR
  • 'X.X.X.X'：対象NAT Gatewayのプライマリプライベート IPv4 アドレスを指定
• 除外する送信元IP/CIDR
  • 'Y.Y.Y.Y/YY'：対象VPCのCIDRを除外。複数CIDRがある場合はand not isIpv4InSubnet〜を繋げる
    
    

filter (dstAddr like 'X.X.X.X') and not isIpv4InSubnet(srdAddr, 'Y.Y.Y.Y/YY')
| stats sum(bytes) as bytesTransferred by dstAddr, srcAddr
| sort bytesTransferred desc

 上記クエリ実行により、データ通信量（bytesTransferred）の多い順で通信先IPアドレスの一覧が得られます。 IPアドレスの一覧をプレフィックスリストと照らし合わせたところ、①、②ともにNAT Gatewayの通信先のほとんどがS3であることが分かりました。

解決策

 先述の通り、NAT Gatewayを利用してEC2↔S3間のデータ通信を行う場合、NAT Gatewayの利用料金とデータ通信料金の2つのコストが発生します。

しかし、VPCエンドポイント(Gatewayタイプ)を利用すると、EC2↔S3間のデータ通信コストは発生しません。
利用料金およびデータ通信料金が無料となるGatewayタイプのVPCエンドポイントが利用できるのはS3、DynamoDBのみですが、Interfaceタイプの場合も、利用料金が0.014USD/時間、データ通信料金が0.01USD/GB(※処理されるデータが1PB/月未満の場合)のため、NAT Gatewayを利用する場合と比べてかなりのコストが削減できます。

S3のVPCエンドポイント(Gatewayタイプ)利用時の注意点

　VPCエンドポイント(Gatewayタイプ)を利用して、S3との通信を行う場合、注意点が2つあります。

VPCエンドポイント設定時の通信遮断

　NAT Gateway経由で接続しているS3をVPCエンドポイント(Gatewayタイプ)経由に変更する際、S3の通信は経路変更のため遮断されます。そのため、設定変更はユーザー影響が少ない時間帯に行う必要があります。

S3のバケットポリシーとVPCのエンドポイントポリシー

　S3のバケットポリシーをEIPで制御している場合は、VPC内部のPrivate IPでの制御に変更する必要があります。VPCエンドポイントを経由してS3にアクセスする場合、通信先はVPC内部のPrivate IPになるため、EIPで制御しているとVPCエンドポイントを設定しても、S3にアクセスすることができません。同様に、VPCのエンドポイントポリシーで特定のバケットへのアクセスのみを許可している場合、S3にアクセスできなくなるため、許可リストに対象のバケットを追加するなどの対応が必要になります。

結果

　EC2↔S3の通信をNAT Gateway経由ではなく、VPCエンドポイント経由としたことで、対象NAT Gatewayのコストを約70％削減することができました。

　今回はNAT Gatewayについて、コスト適正化事例をご紹介しました。
AUCでは、お客様の環境、状況に合わせたコスト適正化を進めていきます。

参考

• https://aws.amazon.com/jp/privatelink/pricing/
• https://aws.amazon.com/jp/vpc/pricing/
• https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpc-endpoints-s3.html
• https://dev.classmethod.jp/articles/reduce-unnecessary-costs-for-nat-gateway/
• https://blog.jicoman.info/2021/05/how-to-analyze-cost-of-nat-gateway-using-vpc-flowlogs/

目次

• 実装前の課題
• 採用した技術と理由
• 実装した内容の紹介
• 改善したこと（抑制できたコスト）

実装前の課題

 SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）とは、Googleが提唱したシステム管理とサービス運用に対するアプローチです。システムの信頼性に焦点を置き、企業が保有する全てのシステムの管理、問題解決、運用タスクの自動化を行います。
弊社では2021年2月からSRE活動を行っており、セキュリティ対策、サーバーのスケールイン/アウト運用化、アラートトリアージ運用化などを行っています。

そういったSRE活動をしていく上で、お客様から「AWSのコストを適正にしたい！」という要望を頂きました。
ヒアリングをしていく上で見えた課題が大きく分けると下記の４つありました。

①コストは月末にチェックしており、月中でコストが急激に上昇した場合発見が遅れてしまう。
② 不要なリソースが放置されていたり、新たなリリースによって生じたコストを確認していない。
③ AWSが提供するベストプラクティスによるコスト最適化が行われていない。
④ コストに対する意識が薄い。

 これらの課題からAWSコストにおける活動視点が2つ見えました。
1. AWSコストの異常値の検知（課題①、②）　
2. AWSコストの抑制活動（課題②、③、④）

2のAWSコストの抑制活動は現存する全てのAWSリソースに対して行う必要があり、手を付けやすく実装に時間がかからない1のAWSコストの異常値の検知を先に実装することに決めました。
（現在も2のAWSコストの抑制活動は継続中です。）

採用した技術と理由

 AWSコストの異常値の検知の実装をするにあたり条件として、全てのAWSサービスを監視できる、なるべく人の手が入らないような運用ができるといったようなことが考えられます。
そのような条件で調査をしていく上で、以下の2つのAWSサービスが候補になりました。
①Cost Anomaly Detection
②AWS Budgets

これらのAWSサービスを簡単に説明します。

①Cost Anomaly Detection

機械学習によって平均コストからの偏差の異常値を検知しそれらの異常値を通知するシステム

②AWS Budgets 　

1ヶ月の予算を設定し、使用状況を追跡して予算を月中で超えた場合にアラートが発生する　

どちらのサービスがお客様の状況に合っているかを考えるために、各サービスの長所・短所を洗い出しました。

 これらの長所・短所を考慮した結果、月中での検知ができ、アカウントやサービス毎に詳細に設定ができる①Cost Anomaly Detectionを採用することに決定しました。 短所は運用でカバーすることを考え、設計しました。次の章で実装の詳細を記述します。

実装した内容の紹介

 今回実装に選んだサービスはCost Anomaly Detectionです。 主要な機能は以下の3つです。(2023年4月時点)

コストモニター

• 機械学習により平均からの上昇値を異常値として検出
• 検知する異常の種類は4つから選択（複数作成可能）

アラートサブスクリプション

• 検出対象の通知要否に異常値の閾値（$100、$1000など）を設定可能
• アラート頻度は3つから選択

検出履歴

• 異常値として検出された履歴

• 検出を評価することでコストモニターの精度を向上させる
  
  
  

  以下にどのような仕組みでコスト異常を通知させるのか説明します。
   まず、平均からのコスト異常をコストモニターが機械学習で検知します。
  下図の例では2つの異常値を検知しています。
  
  

異常値の閾値として、アラートサブスクリプションに$50を設定したとします。
①の異常値は$30で閾値より低いため、通知されません。
②の異常値は$90で閾値より高いため、通知されます。
このようにして、通知されるコスト異常をフィルターすることができます。

通知された異常に関しては、CostExplorerやCloudWatchを使用して原因を解明し対処します。

 また、月の初めに検出履歴を使用し、コストモニターで検知した異常が正確なものであったか評価を送信します。
通知されなかった異常も検出履歴を送信する段階でチェックし、通知はされなかったもののインパクトが大きいものは通知されたものと同様の対処を行います。

以上の実装・運用によりコスト異常をキャッチし、コストを抑制することに成功しています。
最後の章でCost Anomaly Detectionによってコストが減少した例を紹介します。

改善したこと（抑制できたコスト）

 通知された異常としては、プロモーション時のスパイク起因による一過性のコスト上昇のものと、新しいAWSサービスのリリース起因によるコスト上昇があります。
プロモーション時のスパイク起因によるコスト上昇は一過性のものなので対処せず、新しいAWSサービスのリリース起因によるコスト上昇のみ対処します。

 検知したコストの例としては、リリース起因により月初にDynamoDBのコストが上昇し、Cost Anomaly Detectionがそのコスト異常を検知しました。
原因を調査したところ、WriteRequestが増加してることがわかり、不要な書き込みをしない実装を行い、月末に対処が終わりました。
このコスト異常は月$2500のコストであり、早期発見によって抑え込むことができました。

コスト異常検知の紹介は以上になります。

 コスト抑制活動は現在も行っており、抑制活動の一例としてはCloudWatchのログ出力が多く、不要なログ出力を削除することにより、月$4000のコスト削減に成功しています。
これらの活動により、コストインパクトが大きいリソースを対処していけば全体のコストが下がり、コスト異常検知の精度も上昇していくと考えています。

 全てのAWSリソースを最適化することは長い道のりですが、売上を上げることと同様に、コストを下げることも大事なことであるので、AWSインフラの有効活用・改善をこれからも続けていきたいと思っております。