【レポート】金融エンタープライズのミッションクリティカルシステム移行時の勘所 #AWSSummit

どうも、もこ@札幌オフィスです。

今年はAWS Summit Onlineという事で、2020/9/8〜9/9の間のライブセッションと、9/30まで視聴可能なAWS認定セッション、お客様事例セッション、セルフペースハンズオン、Partner Discovery Session (パートナーセッション) などなど、場所を選ばずにオンラインで、好きな時に好きなだけ学べるような環境になっています。

本記事はオンデマンドセッション「金融エンタープライズのミッションクリティカルシステム移行時の勘所」のセッションレポートとなります。

セッション概要

株式会社 QUICK フィンテック事業室 小出 淳二 氏

株式会社 QUICK デジタル推進本部 矢内 隼人 氏

QUICK は、2019 年 11 月に証券会社・銀行のネット向け情報サービス（Amazon EC2 1000 台規模）を１ 年がかりで完全移行しました。移行に際して工夫や注意したポイントを共有いたします。

セッションレポート

Agenda

• 会社紹介
• ネットチャンネル向け株価配信サービス移行のポイント

• QUICKにおけるミッションクリティカルシステムとは

  • QUICKにとって本業サービスであること
  • 社会的影響が大きい証券・金融のお客様を対象にしたサービスであること
  • リアルタイムデータの提供をしておりサービスの知恵にゃ停止が許容されないこと

会社紹介、サービス紹介

• QUICKの全体システム構成
  • 取引所などの情報提供元と専用線接続
  • 最終的に専用線やインターネットを通して情報を提供
  • 今回説明するサービスは個人投資家向けの部分

ネットチャンネル向け株価配信サービス移行のポイント

• QUICKはミッションクリティカルな証券会社・銀行のネット向けサービス(EC2 1000台規模)を1年がかりで2019年11月にAWSに完全移行した
• 全体構成図
  • 右側が証券所などの情報提供元
  • 最終的にはインターネット上のユーザーにデータを構成
    • 構成的にはWeb/DBのWeb系の構成

• 移行に関するポイント
  • AWS環境全体のセキュリティー・ガバナンス
  • オンプレ〜AWS間での設計考慮点
  • Multi-AZ構成の設計考慮点
  • インスタンスタイプ選定
  • オンプレからAWSへのサービス移行
  • WAFの移行

AWS環境全体のセキュリティー・ガバナンス

• 設計思想の異なるAWS環境を案件に応じて使い分けている
• AWS共通基盤環境
  • 自由度 < セキュリティ・ガバナンス
  • ゲートキーパー型環境
• AWS共通基盤"外"環境
  • 自由度 > セキュリティー・ガバナンス
    • クラウドの積極利用を重視した自由度重視
  • ガードレール型環境
• ネットチャンネル向け株価配信サービスはミッションクリティカルなのでゲートキーパー型環境で稼働

• ゲートキーパー型のAWS共通環境基盤環境設計のコンセプト

  • オンプレのデータセンターの延長としてAmaozn EC2を中心とする
  • Amazon EC2以外のサービスも利用することで開発・効率性を高める
    • ※現在は30個以上のサービスを利用可能
  • オンプレとの接続、セキュリティー・ガバナンス観点の考慮、設計・運用体制、各種ルール、社内申請などが整備された環境
  • その枠内でセルフマネージドな(オンプレに比べて)自由度の高い環境
• セキュリティー・ガバナンス観点
  • ゲートキーパー型
  • 利用サービスの限定・ルール化
    • 基盤担当がAWSサービスを調査して社内基準に照らして利用可否を判断
    • 利用方法をルール化
  • 権限を絞ったユーザー提供
    • IAMユーザーを基盤担当からシステム担当へ提供する事で権限を制限
  • CloudTrail, AWS Config, GuardDutyなどを有効化して、通知設定も行っている
  • ルールチェックを自動化してルールが保たれているかを確認
• ルールチェックの例
  • Security Group / Amazon S3 / Lambdaの権限チェックなど
  • AWS一般論的なチェックだけでは無く、社内基準に応じたチェックもサービスの調査段階で穴になりそうだと判断したポイントをチェックしている
  • Config Rulesだけではなく、Lambdaを活用して自前でチェックの仕組みを構築
• AWS共通基盤"外"環境
  • AWSの積極利用を主目的とし、システム担当者の自由度を最大化
    • 制限をほぼ設けず全ての権限を利用可能
    • 基盤担当者はガードレールの設置、AWSアカウント作成、請求代行、ルートアカウントの管理などだけを担当
    • システム担当者にAWS資格保有者(SAA)がいることが環境提供の条件
  • 自由度を下げずにセキュリティー・ガバナンスを高める
  • システム担当者の手を止めないで、リスクや問題があったときに気づくことが出来るように
  • Landing Zoneでガードレールを作成
    • 自社に合わせてカスタマイズ
    • CloudTrail, AWS Config, GuardDutyなども有効化
    • Config Rulesでのルールチェックを実施
    • CloudFormation / StepFunctionsでガードレールの構築も半自動化
• AWS環境全体のセキュリティー・ガバナンスのまとめと今後の課題
  • AWSの積極利用を進める際はガードレール型の考えが現実的
  • ただしゲートキーパー型に比べるとガードレール型は考慮が漏れる範囲が大きいので全てのシステムがガードレール型で十分だとは考えていない
  • ミッションクリティカルシステムに関しては今のところゲートキーパー型が望ましいと考えている。ただし今後それらのシステムにおいても多様なAWSサービスを活用することになるので、何が最適なのかは今後の課題

オンプレ〜AWS間での設計考慮点

• 冗長化
  • パートナー回線では独自設計余地が足りなかったので自社で調達して設置
  • キャリアロケーションを別けて単一障害を受けないように
  • Active Standby
  • WAN回線でDXの切り替わりが起きないようロケーション間はWAN回線で接続
• 障害時の通信影響
  • リアルタイムデータを提供しているため遅延を気にしている
  • BGPに加えてBFDを採用している
  • DXはConnectionは切り替わらず影響リソースが限定された通信断も発生する
  • サービス上許容できない通信断が発生したら通信先を切り替えるか該当構成をサービスから離脱するなど考慮が必要
• QUICKでは10G回線を利用している
  • 複数システムで利用しているのでトラフィックはなるべく削減したい
  • 4~5msの遅延が発生するので何度も往復する構成は抑える

Multi-AZ構成の設計考慮点

• AZ間で2.5ms程度の遅延が発生するので積み重ねると秒単位の遅延が発生した
  • レガシーな密結合アプリは要注意
  • 各AZ内で通信が完結するようアプリケーションを配置

• インスタンスタイプの選定
  • 新しいインスタンスタイプは価格は下がって性能も向上
  • Nitroをかなり初期に採用したため不具合(現在は解消済み)に直面して移行計画の見直しが発生
    • 全部c4, m4インスタンスで作り直した
  • ミッションクリティカルシステムでの採用は枯れてからが無難
    • 東京リージョンで利用可能になってから1年後くらい
    • Amazon RDSでインスタンスタイプが利用可能になったタイミング
    • AWS一般論ではないQUICKのノウハウ
• オンプレからAWSへのサービス移行方式
  • AWSにオンプレ同等のフルセットを構築してテストを行った
  • サービスの移行は切り替えはDNS切り替え
  • 300近くのサービスを約70ステップに別けて1年かけて移行
  • IPアドレス固定が必須なサービスはNLBを利用
  • バックエンドにHTTP1.0が必須のレガシーサービスはNLBで構築
  • 株価等のDBは音プレトAWSの両アクティブ構成で最新データを保持
  • 登録情報等のDBは週末深夜にオンプレからAWSに移行

WAF選定のポイント

• WAF選定ポイント
  • 金融ミッションクリティカルシステムにおけるAWS WAFとWAFアプライアンスの使い分け
  • WAFアプライアンス設計のポイント
  • WAFアプライアンスのよい点、イマイチな点
• 使い分けのポイント
  • 機能要件
    • WAFでどういう防御や保護を実現したくてどこまでの機能が必要なのかを明確に
      • 誤検知時にセキュリティーポリシーの修正がピンポイントで出来る事
      • WAFアプライアンス
        • きめ細かい設定が可能
      • AWS WAF
        • 細かいチューニングは出来ない
    • シグネチャーのステージング機能で新しいシグネチャーで誤検知が無いかを事前に確認したい
      • WAF アプライアンス
        • シグネチャのステージング機能あり
      • AWS WAF
        • フルマネージドルールの場合不可
    • クレジットカード番号のマスキングしたい
      • WAFアプライアンス
        • 保護機能あり
      • AWS WAF
        • アウトバウンドトラフィックは制御できない
    • CSRF, パラメータ・タンパリング、セッションハイジャック攻撃などを防ぎたい
      • WAFアプライアンス
        • 実装可能
      • AWS WAF
        • 対応不可
    • グラフィカルなレポーティング機能が欲しい
      • WAFアプライアンス
        • 提供可能
      • AWS WAF
        • グラフィカルなレポーティング画面はない
    • まとめ
      • 機能面ではWAFアプライアンスに軍配があがるかどこまでの機能が必要なのかを精査して選定する必要がある
  • 非機能要件
    • 可用性
      • WAFアプライアンス
        • MultiAZがそれなりに大変
      • AWS WAF
        • マネージドでMultiAZ
    • 性能拡張性
      • WAFアプライアンス
        • 柔軟にスケール出来ない
      • AWS WAF
        • 圧倒的なスケーラビリティ
    • 運用/保守性
      • 金融ミッションクリティカルシステムでの一番のポイント
      • SOCを委託するケースが多い
      • WAFアプライアンス
        • 複数ベンダーを洗濯可能
      • AWS WAF
        • 24h/365dで緊急対応が可能なベンダーがなかった
          • Shield Advancedと絡めば24h/365dのプロアクティブなサポートが得られる物の日本語サポートなし
    • コスト
      • WAFアプライアンス
        • スモールスタートが出来ない
        • 初期の設計、構築費用が必ず必要
      • AWS WAF
        • スモールスタート可能
        • 従量課金でコスパがいい
  • QUICKはWAFアプライアンスを選択した
    • ALBにてWAFアプライアンスのサンドイッチ構成
    • Multi-AZのActive-Active構成
    • スモールアウト構成
    • ブロックモードで運用
• 設計のポイント
  • スケールアウトな構成を行う
  • 複数台同じ設定を行えるようにクラスタのアドレスを設定
  • WAFアプライアンスでSNATを行うが固定アドレスにすると同じ設定が出来ないのでスクリプトで生成するよう設計
  • WAFアプライアンスの構成変更の影響を受けない設計
    • 障害でインスタンスが作り直したりしても、ALBでサンドイッチしているのでALBの設定の変更をしなくても良いように実装
• WAFアプライアンスの良いところ、悪いところ
  • 良いところ
    • 非常に安定している
    • 機能が充実している
    • 充実した管理画面
    • スケールアウト構成が可能
  • イマイチなところ
    • 高い(SI費用も発生)
    • 設計が必要
      • お手軽にボタン一つで導入できる物ではない
    • 構成が複雑、切り分けが大変
      • 色々な点でログを分析する必要がある
    • ソフトウェアEOLとの戦いが続く

まとめ

- WAFは運用を含めて考える必要があり、運用体制の構築が必要
    - AWS WAFは検討当時対応ベンダーがなかった
- QUICKはWAFアプライアンスを選定
- WAFアプライアンスはオンプレと変わらない感があるので今後のAWS WAFの機能拡張等に期待したい