【AWS事例】SBIホールディングスが公開Webサーバでセキュリティとスケーラビリティを両立できた理由

「成果」

結論から申し上げますと、AWS活用によって以下のような成果を得ることができました。

スケーラビリティの確保

サービスキャパシティに上限が無い、Route53やAWS WAFなどのAWS マネージドサービスを採用。（CDNは既存WEBサイトの移行を考慮し他ベンダの高セキュリティCDNサービスを継続して利用）インターネットからの着信トラフィックを効率良く制御し、オリジンサーバの負荷を低減させるアーキテクチャを採用しています。

また、オリジンサーバ上位ではApplication Load Balancer(以下、ALB)を採用し、負荷急増時にはクラウドのアジリティ(機敏性)を活用したスケールアウトも可能にしています。

セキュリティの確保

CDNでは標準的にDDoS対策がされていますが、CDNを経由しない通信なども制御可能なようにさらにAWS WAFを採用しました。また、IPSの仕組みとしてALB配下には仮想アプライアンスである「PaloAlto」を設置し、オリジンへ到達するトラフィックを極限までクリーンなものとすることに成功しています。

スケーラビリティ確保との両立が難しいセキュリティ部分についても、金融機関としてSBIHD社が要求される厳しい水準をクリアすることができました。

運用の効率化・自動化の促進

WAFはグループ内サイト毎に1系統、ALB配下に配置しています。一見管理が煩雑になりそうなこのアーキテクチャも、実際の運用シーンとしてはサイト個別のポリシー運用としてWebサイト単位で運用をオフロードできるため、むしろ効率的であるという結論に至りました。

また、今回公開WEBサーバは別VPC上への配置となるため、本VPCがゲートウェイとしての機能をフェールセーフに保つため、ヘルスチェック用のNLBを配置しNLBのヘルスチェック失敗によりLambdaが発火し、TransitGWのルートテーブルを動的に変更するという、運用自動化も取り入れております。

AWSサービスは自由度も高く、柔軟でコストパフォーマンスに優れた環境を提供してくれますが、一方でシステムの複雑さに比例してユーザが考慮するべき事項も多くなります。

以下はクラウド原則である責任共有モデルの図をベースとしていますが、本来ユーザ側の考慮事項となるような各種考慮事項に対し、ベストプラクティスを一緒に探ること。

こうした点も、ソフトバンクSEが介入する価値と考えています。

次章以降では、CoEとしての活動の中で具体的にどのようなサポートを差し上げたのか、実例をベースにご紹介差し上げます。

「選定・戦略」

AWSは構成の自由度が高く柔軟な構成が組める一方で、アーキテクチャを選定する難易度も高くなりがちな側面があります。

今回はAWS WAFやCDNとして他ベンダの高セキュリティCDNサービスの導入が内定していましたが、WAFの設置単位は、グループ全体で1つとすることもできましたし、サイト毎に個別で配置することも可能でした。

具体的には図03の通りです。

　SBIHD社との会話の中で、「柔軟性」「運用面」「コスト面」「ALB構成容易性」の4つの軸で検討を進め、今回ソフトバンクではSBIHD様のご要件を踏まえ、図03のアーキテクチャから①をご推奨差し上げました。

①案のウィークポイントは、「運用面」「コスト面」の2点でしたが、「コスト面」については柔軟性とのトレードオフとしてご選定をいただき、「運用面」ではWebサイト単位で運用をオフロードできるため、むしろ効率的であるという結論を導き出すことができました。

システム設計は積み重ねですから、システムの運用開始後に例えば図03の構成案を変更しようとなると、非常に大がかりな改修が必要になってしまいます。

「実際の運用シーンまで考慮した設計」を差し上げられたこと。今回ソフトバンクSEが介入したバリューとして、SBIHD様からもご評価をいただいたポイントです。

「運用の効率化・自動化の促進」

ベストプラクティスに沿った構成とは、システムカットオーバー後の運用まで見越したものでなければなりません。

運用負担を可能な限り引き下げ、自律した運用ができることが、良いシステムの条件だと考えます。

少しトリッキーな手法ですが、本環境では図04の通りNLBのヘルスチェック機能を利用することで、Paloaltoの健全性を監視する仕組みを導入しています。

ヘルスチェックの失敗時には図05のように、SNS経由でのメール通知以外に、Lambdaが実行される実装となっています。

実際にNLBのヘルスチェックが失敗しこのLambdaが発火すると、図06の通り、Lambdaによって画像向かって右側となる AvailabilityZone-Cにデフォルトルートが向くよう、VPCルートテーブルを書き換えに行きます。

実装にあたっては想定される各障害ケースにおける動作テストとチューニングを繰り返し実施し、「実際の運用に耐えるのか？」やあるいは「切り替わり/切り戻しにかかる時間はどの程度か？」などの試験を行い、設計上の仕様とギャップがないように実装していくという、地道な作業を繰り返しました。

泥臭い作業ではありますが、自律的なシステムを手に入れるためにはこのような実装テストや障害試験が欠かせません。

絵空事に終わらせず、地に足をつけて実装をやり切ることもまた、ソフトバンクSEが介入するバリューだと考えています。

最後に

図02で示した責任共有モデルの考え方は、AWSの自由度とトレードオフでユーザに重くのしかかる課題です。

さらにAWSサービスは日々進化しているため、半年前のドキュメントはすでに陳腐化していることも多く、常に最新の動向をキャッチアップし続けるスタミナも必要です。

こうしたユーザを取り巻く課題に対して、我々ソフトバンクSEは仮想クラウドCoE(Center of Excellence)としてお客さまと共に日々伴走をしています。

AWSに関する導入課題などございましたら、ソフトバンク法人向けAWSページよりお問い合わせください

関連サービス