style

border-bottom-glow

AWSにおけるログ保持の管理：S3ライフサイクルルールとTerraformのベストプラクティス

クラウドコストが気づかないうちに増加する最も簡単な方法の一つは、ログの保持です。多くの組織はログを収集することの重要性を理解しているが、ログから得られたデータを最適化して活用する方法を理解している組織は少なく、さらにログをどのくらいの期間保存すべきかを理解している組織はごくわずかである。自社がこれらのログにどのくらいの頻度でアクセスしているか、また現在のストレージ戦略がビジネスニーズに合致しているかどうかを把握することが重要です。

顧客と協力してログ記録戦略を見直す中で、共通のパターンが明らかになりました。ログが必要以上に長く保持されていること、ストレージコストが増加し続けていること、そして環境間で標準化されたライフサイクルポリシーが存在しないことです。

この課題に対処するため、Amazon S3ライフサイクル管理とInfrastructure as Code（IaC）を活用した正式なログ保持ポリシーを策定しました。その結果、ログ管理に対するより一貫性のあるアプローチ、ストレージコストの削減、そして運用要件とコンプライアンス要件により合致した保持戦略が実現した。

ストレージクラスではなく、目的から始めましょう

組織が犯す最大の過ちの一つは、ビジネス要件ではなく技術から出発してしまうことだ。

多くの従業員の権利保持に関する方針は、「もしも」のシナリオに基づいて構築されている。

2年前のログが必要な場合はどうすればいいですか？
調査で12ヶ月前の履歴データが必要になった場合はどうすればよいでしょうか？
もし誰かが、私たちが既に保管していない記録を要求してきたらどうすればいいでしょうか？

これらの疑問はもっともだが、結果としてすべてを永久に保持してしまうことになりがちだ。

代わりに、まずはいくつかの簡単な質問から始めてみましょう。

これらのログの実際の目的は何ですか？
それらはどのくらいの頻度でアクセスされますか？
それらが利用された際に、どのようなビジネス価値を提供するのか？
法令遵守上、保存期間を規定する要件はありますか？
ログの保持に関する決定権は誰にありますか？
何も犠牲にすることなく、保管コストを削減するにはどうすればよいでしょうか？

これは企業によって異なりますが、多くの場合、数か月以上前のログはほとんどアクセスされず、運用上の価値も限られていることがチームによって明らかになります。それらは安心感のために存在するが、気づけばテラバイト単位の不要なコスト増加の原因となる容量と不要なデータが蓄積されてしまう。

最終的な目標は、不必要な保管コストを避けつつ、調査、問題解決、コンプライアンス、監査を支援するのに十分な期間ログを保持することである。

環境によってニーズは異なる

すべての環境において、同じ保存期間が求められるわけではありません。

運用ログは、監査、インシデント対応、およびセキュリティ調査を支援するために活用されることが多い。開発ログは通常、短期的なデバッグに使用され、通常ははるかに短い期間しか保持されません。

当社の人材維持戦略は、環境特有の要件に基づいて構築されました。以下に、その表示例を示します。

生産

保持期間： 12ヶ月

本番ログは、以下の内容をサポートするため、最も長い保存期間が必要です。

セキュリティ調査
インシデント対応
コンプライアンスおよび監査要件
過去の運用分析

ライフサイクル戦略：

0～30日目：S3標準
31～90日目：S3スタンダード-IA
91～365日目：S3氷河フレキシブル回収
12か月後に削除

品質保証

保持期間： 90日間

QAログは主に以下をサポートします：

リリース検証
回帰分析
過去のトラブルシューティング

ライフサイクル戦略：

0～60日目：S3スタンダード-IA
90日後に削除

発達

保持期間： 30日間

開発ログは主に以下の目的で使用されます。

アプリケーションのデバッグ
トラブルシューティング
開発サポート

ライフサイクル戦略：

0～30日目：S3スタンダード-IA
30日後に削除

各環境に合わせてデータ保持要件を調整することで、必要のない場所で高額な本番環境レベルのデータ保持要件を適用することを回避しました。

適切なS3ストレージクラスの選択

Amazon S3は、それぞれ異なるアクセスパターンに対応するように設計された、複数のストレージクラスを提供しています。

重要な教訓は、ストレージクラスの選択は、憶測ではなく実際の使用状況に基づいて行うべきだということである。

検討すべきいくつかの質問：

ログへのアクセス頻度はどのくらいですか？
特定のログは他のログよりも高く評価されるのでしょうか？
現在、当社のS3バケットはどのように設定されていますか？
それらは最初の1か月以降はほとんどアクセスされないのでしょうか？
それらはどれくらいの速さで回収されなければならないのか？
回収費用は許容範囲内ですか？

私たちのユースケースでは：

S3規格

即時アクセスが重要な、新規作成された本番ログに使用されます。

S3スタンダード-IA

ログへのアクセスは時折必要となるものの、もはや標準規格に準拠する緊急性を必要としない場合に使用されます。

S3 氷河フレキシブル回収

アクセス頻度は低いものの、必要に応じて検索が可能な長期保存用資料として使用されます。

AWSは、利用可能なS3ストレージクラスとそのトレードオフに関する詳細な内訳を提供しており、こちらで確認できます。
https://aws.amazon.com/s3/storage-classes/

インフラストラクチャ・アズ・コードによりガバナンスが容易になる

従業員保持ポリシーは、一貫して実施されてこそ価値がある。

環境ごとにライフサイクルルールを手動で設定するのではなく、Terraformを使用してライフサイクルポリシーを実装しました。

これにより、いくつかの利点がもたらされた。

再利用可能なライフサイクル構成
バージョン管理された変更
プルリクエストによるピアレビュー
環境を問わず一貫した展開が可能
設定のずれのリスクが低減

インフラストラクチャ・アズ・コードは、データ保持管理を一度限りの設定作業から、繰り返し実行可能な運用プロセスへと変革させた。

ミスから身を守ろう

ライフサイクルポリシーは、削除とストレージの移行を自動化します。それは彼らを強力にする一方で、潜在的に危険な存在にもする。

自動有効期限切れと自動移行を有効にする前に：

S3バケットのバージョン管理を有効にする
非本番環境でライフサイクルルールを検証する
遷移タイミングの計算結果を確認する
テストオブジェクトの有効期限動作
取得ワークフローを確認する
適切なバケットがターゲットになっていることを確認してください

バージョン管理は、誤って削除したり、ライフサイクルルールを誤って設定したりすることに対する、追加の保護層を提供します。

生産前にテストを実施

展開前に、シンプルな検証プロセスを確立しました。

専用の開発用バケットを作成します。
開発ログをバケットにアーカイブする。
提案されたライフサイクルポリシーを適用する。
ストレージクラスの遷移を検証する。
有効期限切れ時の動作を確認してください。
結果を記録する。
他の開発バケットに進む前に承認を得てください。
より高い環境へ昇進する

このアプローチにより、リスクを最小限に抑えながら、設定上の問題を早期に特定することができました。

ガバナンスは重要だ

ログの保持は、一人のエンジニアが独占すべきではない。

効果的な人材維持策には、以下の関係者間の連携が必要です。

DevOpsチーム
セキュリティチーム
コンプライアンスチーム
インフラストラクチャのリーダーシップ

明確な所有権の確保は、システムの進化に伴い、データ保持期間がビジネス要件および規制要件と整合していることを保証するのに役立ちます。

最後に

最も効果的なログ保持ポリシーは、必ずしもログを最も長く保持するポリシーとは限りません。

それはバランスを取るものです。

料金
コンプライアンス
安全
運用状況の可視化
シンプルさ

組織は、実際の業務要件ではなく、将来の想定されるニーズに基づいてデータを保持することが多い。ログの使用方法を理解し、環境固有のニーズに合わせて保持期間を調整し、適切なS3ストレージクラスとストレージ移行を活用し、IaCを通じてポリシーを実装することで、チームは実際に必要な可視性を維持しながら、ストレージコストを大幅に削減できます。

最も重要なことは、組織はそれぞれ異なるということを覚えておくことです。ここで説明したライフサイクル戦略は、私たちの事例ではうまく機能しましたが、保持期間、ストレージクラス、およびアーカイブのタイムラインは、常に自社の運用要件とコンプライアンス義務に基づいて決定されるべきです。