AZ障害が起きてもOK？ バックアップは？ インスタンス購入方法は？――AWSの本番環境を設計する際の3つのポイント：セキュリティログ基盤クラウド化検討大解剖（終）

リクルートのSOCによるログ基盤クラウド化検討プロジェクトの概要や失敗談、そこから得た学びを紹介する連載。最終回は、本番環境を設計する上で考えておくべき3つの検討ポイント「拡張性」「運用性」「インスタンス購入方法」について解説する。

[田村由佳，リクルート]

　セキュリティオペレーションセンター（SOC）によるログ基盤クラウド化検討プロジェクトの概要や失敗談、そこから得た学びを紹介する本連載「セキュリティログ基盤クラウド化検討大解剖」。前回は、Amazon Web Services（AWS）上でSplunkを構築するにはどういった構成がよいか、検証結果を交えて解説しました。最終回では、前回の検証結果を踏まえ、本番環境を設計する上で考えておくべき検討ポイントについて、特にお伝えしたい拡張性、運用性、インスタンス購入方法の3つを解説します。

拡張性の検討ポイント

スケールアウト？　スケールアップ？

　Splunkの拡張方式として、スケールアウトとスケールアップのどちらを採用するのがいいのかを解説します。検証結果を考慮すると、コンポーネントごとに下記の方式を取るとよいと考えています。

Splunkの拡張方法

　まずはSplunk管理サーバについてです。Splunkの機能では、クラスタリングできないので、管理する対象が増えることによって性能が不足する場合には1台のノードをスケールアップさせることになります。

　次にSearch Headです。1つのサーチにつきCPUのコアを1つ消費します。同時に実行するサーチ数を増やしたい場合は、スケールアップとスケールアウトのどちらの方式でも対応可能です。個々のサーチの検索性能を向上させたい場合はCPUコアの周波数が影響するので、CPU周波数の高いインスタンスタイプにスケールアップすることになります。

　最後にIndexerやHeavy Forwarderです。スケールアウトさせることで性能が向上するので、同じインスタンスサイズで複数台並列に並べる構成にするのが望ましいと考えています。ただし、AWSで構築する上でスケールアウトさせる際に考慮すべきポイントがあります。

スケールアウト時の考慮事項

　EC2インスタンス（以降、インスタンス）をスケールアウトする際に考慮すべきポイントは、インスタンスの配置場所と増やし方です。特に、Indexerはデータを保管しているコンポーネントです。データのコピーを複数保持する機能があるので、配置する場所と増やし方が重要になります。

　AWSには「Availability Zone」（以降、AZ）という仕組みがあり、インスタンスを配置する物理的なデータセンターを分散させることでシステム全体の可用性を高めることができます。ごくまれにAZ単位での障害が起こるので、1つのAZに全てのIndexerを配置すると、運が悪く全てのデータが検索不可となってしまいます。東京リージョンの場合は3つのAZ（1a、1c、1d）にIndexerを均等に分散配置し、AZ障害時でもデータを検索可能な状態にしておくことで可用性を高めることができます。

　Indexerのインスタンス数を増やす場合も特定のAZに偏らないように分散させて拡張します。拡張時は、Splunkの「レプリケーションファクター」（以降、RF）という設定項目が重要です。

　RFはデータの可用性を保証するためのパラメーターです。何台まで障害を許容できるのかに応じて設定します。許容できる台数＋1でRFを設定することで、障害時もデータの可用性を保証できます。AZ障害が発生してもデータを失わないようにするには、RFで設定した値よりも1つのAZに置くIndexerの台数が少なくなるように設計します。むやみにRFを増やし過ぎると、今度はレプリケーションによるオーバーヘッドが増大します。バランスを考慮して設計する必要があるのが、難しいポイントです。

データが欠損する場合

　障害許容台数を2台にしてRF＝3に設定した場合、1つのAZ内にIndexerを3台配置するとAZの1aに障害が発生した際に障害許容台数以上のIndexerが停止してしまうので、検索できなくなってしまいます。

データが欠損しない場合

　同じ条件でも、Indexerを他のAZに配置することで、データの欠損を回避できます。上図の場合、AZ障害時に停止するIndexerは許容台数の2台です。このとき障害が発生していないAZの1cにもIndexerが配置されているので、データが欠損することなく検索できます。

運用性の検討ポイント

　連載第1回で課題に挙げていた運用性について「どのような改善が可能なのか」「具体的にどのようなバックアップ方法が取れるのか」「どのようにステージング／開発環境を構築するのがいいのか」といった検証内容にも触れながら解説します。

EBSスナップショットとAMIの使い分け

　AWSのインスタンスのバックアップには、「Amazon Elastic Block Store」（EBS）スナップショットや「Amazon Machine Image」（以降、AMI）を使用した大きく2通りの方法が考えられます。

　EBSスナップショットによる方法では、バックアップ対象のインスタンスが使用しているEBSボリュームのスナップショットを作成しておき、インスタンスの障害時にマウントされているEBSボリュームと置き換えることでスナップショット作成時点にリストアできます。後述しますが、SplunkにおいてEBSスナップショットの利用は推奨されていないので、使用する際は考慮が必要です。

　AMIによる方法では、バックアップ対象のインスタンスのマシンイメージを作成します。リストア時は新規に別インスタンスとして起動することでマシンイメージ作成時点に戻せます。

　どちらの方法も現行システムのようなバックアップ用スクリプトを作成する必要がなく、作成したスナップショットやマシンイメージは自動的に「Amazon S3」に保管されるので、バックアップ先のストレージを別途用意する必要もありません。S3に保管されたバックアップはS3の高い可用性で冗長化されているので、ロストすることもありません。

　2つの手法における大きな違いは、リストア先が「既存のインスタンス」か「新規のインスタンス」かにあります。AMIからのリストアでは新規のインスタンスとなるので、IPアドレスやホスト名が変わってしまいます。Splunk管理サーバの登録内容に修正が必要です。一方、EBSスナップショットは既存インスタンスのボリュームを置き換えることになるので、IPアドレスやホスト名は変わりません。

　弊社では、リストア後にIPアドレスやホスト名の変更を実施したくなかったので、本番環境のバックアップにはEBSスナップショットを使用しました。一方でステージング／開発環境では必要なときにインスタンスを作成し、不要になったら削除する使い方が想定され、こちらはIPアドレスやホスト名が変わっても問題ないので、AMIを使用しました。

バックアップ方法

　EBSスナップショットからインスタンスをリストアした際、データに不整合が発生しないかどうかを検証しました。具体的なシナリオとしては、Splunkコンポーネント単位でのインスタンス障害（シナリオ1〜3）と、管理系のコンポーネントが稼働しているインスタンスを配置しているAZにおける障害（シナリオ4）を想定して検証しています。

リストア検証シナリオ

　シナリオ4の場合はデータの不整合が発生するので、Indexerはシステム領域のみバックアップ対象とします。結果として、リストア時はデータ領域として空のEBSボリュームをマウントし、データ復旧自体はSplunkのレプリケーション機能によって実施するのが望ましいことが分かりました。

　AZ障害などでCluster MasterとIndexerが同時にダウンした場合、スナップショット作成時点で「Hotバケツ」になっていたバケツに取り込まれたデータは一部欠損します。

　リストアによってCluster MasterやDeployerの設定にデグレードが発生すると、設定配布先のIndexerやSearch Headの設定もデグレードしてしまうので、注意が必要です。

ステージング／開発環境

　AWSにおけるステージング／開発環境の在り方についても検討しました。ステージング／開発環境は、どちらの環境も本番相当のデータを保持する想定です。ステージング環境は、バージョンアップ検証や開発したサーチ文の負荷試験などを目的として、本番同等の構成で検討しました。一方で開発環境はアナリストがサーチ文を作成するのを目的として、ミニマムな構成とするのがよいと判断しました。

　まずは、本番相当のデータを持たせる方法を検討しました。オンプレミスでSplunkを構築する場合、本番環境に送るデータをステージング／開発環境にも送る必要があります。しかしAWSでは、【1】S3にデータを集約して他の環境で利用する方法、【2】本番環境のインスタンスのAMIから環境を作成する方法の大きく2つが考えられます。

オンプレミスでステージング／開発環境に本番相当データを持たせるには

　オンプレミスにおいて、本番環境とステージング／開発環境にデータを送信する際の壁として、各環境がネットワーク的に分離されているようなケースが想定されます。

AWSでステージング／開発環境に本番相当データを持たせるには（S3を使用する場合）

　【1】S3にデータを集約して他の環境で利用する方法は、S3にデータを集約し、本番環境とステージング／開発環境のSplunkからデータを取得する方法です。送信元はデータをS3にアップロードするだけなので、二重送信は不要になります。

AWSでステージング／開発環境に本番相当データを持たせるには（AMIを使用する場合）

　【2】本番環境のインスタンスのAMIから環境を作成する方法は、本番環境にのみデータを送信します。インスタンスに格納されたデータごとAMI化し、そのAMIからステージング／開発環境にデプロイするので、取り込みにかかる時間を短縮できます。

　ステージングおよび開発環境の構築方法を少し紹介します。

ステージング環境構築方法

　ステージング環境では、本番環境の全インスタンスのAMIを作成し、本番環境に影響を与えないように事前に作成したステージングVPC（Virtual Private Cloud）にデプロイしました。その後、Splunkの設定ファイルに記載されているIPアドレスを変更し、Search Head Clusterを再設定することで、本番相当のデータを持ったステージング環境を構築できました。

　開発環境では、クラスタ構成の本番Splunkからスタンドアロンの開発環境を作っているので、少し複雑なステップになっています。

開発環境構築方法

　開発環境はCluster Masterが含まれているSplunk管理サーバとIndexer1台のAMIを作成し、開発VPCにデプロイして作成します。一度Splunk管理サーバから開発環境Splunkに検索するのは、開発環境Splunk内の検索できない状態のデータを検索可能な状態にするからです。その後、開発環境Splunkをスタンドアロン化することで本番相当のデータを持った開発環境を構築できました。

　データの鮮度や整合性は保証されませんが、クエリの開発環境として利用するには十分です。容易かつ迅速に本番相当のデータを保持した環境を手に入れることができます。

インスタンス購入方法の検討ポイント

インスタンスの購入方法

　これまで触れませんでしたが、本番環境を設計するに当たり費用対効果を最大化するためにはインスタンスの購入方法についても幾つか考えるべきことがあります。

検討したインスタンスの購入方法

　弊社では、上記の購入方法を検討しました。それぞれの購入方法にはメリットとデメリットがあるので、「インスタンスをどのように使用するのか」が重要です。詳細は「インスタンス購入オプション - Amazon Elastic Compute Cloud」をご参照ください。

最適な購入方法を選ぶ

　これまでの検証結果や拡張性、運用性を踏まえて、改めて各インスタンスをどの方法で購入すると最適化されるかを検討しました。

購入方法を選んでみる

　常時起動が必要なインスタンスは、割引率が高く柔軟性のある「Savings Plans」（以降、SPs）とし、ステージング／開発環境のような必要なときのみ起動するインスタンスは、「リザーブドインスタンス」（以降、RI）やSPsにするメリットがあまりないので、「オンデマンドインスタンス」としています。

　バッチログ取り込みに使用するHeavy Forwarderは、毎日特定の時間帯のみ稼働していればいいので、スポットインスタンス化することでコストを抑えることができると考えています。1日当たりの起動時間によってはRIやSPsの方が安くなることがあるので、損益分岐点を試算した上で購入方法を決定する必要があります（弊社では1日9時間稼働すると想定した場合、SPsの方がコストを抑えられたので、SPsを検討しました）。

　拡張方法がスケールアウトの場合は、必要になった際にSPsで購入することを想定しています。

　昨今は、物理サーバも安く手に入るようになっていると聞いていたので、単純なクラウドへのリフトではオンプレミスよりもコストが高くなってしまうのではないかと考えていました。しかし、最適な構成を追求して最適な購入プランを選択することで、コストを抑えつつもクラウドのメリットを享受できました。この知見は、本検証プロジェクトにおける最大の成果となりました。

終わりに

　本連載では3回に分けて、ログ基盤クラウド化検討プロジェクトの中で実施、検討した内容について解説しました。筆者は未熟で、知識や技術において至らない部分が多々ありますが、本プロジェクトの検証を通して勉強になることが多くありました。得られた学びを少しでも多く共有できたらと思い、本連載を寄稿しました。今後の皆さまの業務に少しでも役に立つことがあれば幸いです。

筆者紹介

田村 由佳（たむら ゆか）

株式会社リクルート リスクマネジメント担当 セキュリティ推進室 セキュリティオペレーションセンター ソリューションアーキテクトグループ 兼 インシデントレスポンスグループ所属。

5年間、SIerに在籍。インフラエンジニアとして、主にサーバやセキュリティアプライアンスの設計や構築を担当。2018年から現職において、Splunk基盤の運用や次期ログ分析基盤の検証を担当。現在はインシデントレスポンスグループで攻撃者の思考回路をトレースしながら、どんな悪いことができるのか日々勉強中。BigQueryやSplunkなどを用いたログ分析に情熱を注いでいる。