連載
» 2021年06月24日 05時00分 公開

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の使い分け

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。