【参加レポート】「金融サービスでECS/Fargateを設計するということ」を聞いて感じたこと
遅まきながら参加レポートを発信します。
すでに動画も講演資料も参加ブログも充実しているため、
「金融サービスでECS/Fargateを設計するということ」という素晴らしい講演で感じたことを金融SIerで働くエンジニア目線でまとめてみました。
パブリッククラウドサービスと業界標準ガイドラインに対し、ここまで誠実に向き合った発表事例は稀ではないでしょうか。
自身も金融系でECS/Fargateを利用したシステム設計に携わっているものとして、考慮すべきことを再認識できた良い機会でした。
=====================================================
【注意】この記事は個人の見解を述べたものであり、発表者様の意図・思想を反映させたものではございません。
=====================================================
講演内容を見てない人は以下のリンクからどうぞ。
基幹系もクラウドに移行するほど金融業界は変化している
「1. 金融サービスの変化」では、Fintech企業の台頭や、改正銀行法によるバンキングAPI提供の努力義務化などにより、ユーザの行動の変化だけでなく、金融サービス提供側の業界構造も変わっていると述べられています。
確かに、PayPayなどの決済サービスや、freeeなどの会計サービスの情報を聞かない日がないほど、Fintech業界の成長は日進月歩の様相です。一方で、それらFintechサービスからAPIコールを受ける側の金融基幹システムでも、パブリッククラウドサービスでシステムを再構築するといった大きな変化が起きています。
一般に、金融基幹系(勘定系)システムといえば、重厚長大で一つの不整合も許されない堅い世界です。システム維持費だけでも莫大なコストがかかっており、レガシーシステムへの改修期間・費用は、バンキングAPI利用料設定だけでも全銀協が取りまとめるほどです。上記銀行がクラウドへ移行する目的は、維持費削減だけでなく、新サービス開発や、将来の法改正にも速度感を持って対応可能にしていくことであることと認識しています。
ECS/Fargateによって利用者が得られる効用は凄まじい
「2. ECS/Fargateという選択」では、ユーザ価値向上に寄与するビジネスロジックの開発に集中するために、ECS/Fargateを基盤として選択することで
運用負荷を最小限にできたと述べられています。また、信じられないことにASPのコンテナ実行基盤を一人で構築したそうです…
お試しでECS/Fargateを使うのは非常に簡単です。コンソールから数カ所の設定値を入力し、ものの数分足らずでECSサービスを作成できた経験がある人は多いのではないでしょうか。しかし、金融サービスとして設計・構築するとなると考慮しなければならないことが急激に増加します。デフォルト値として処理されていた全てのプロパティに対して、なぜその値で良いのかの明確な根拠が必要になってきます。当然ながら、それらの設定値は機能/非機能要件を満たすだけでなく、FISC安全対策基準やPCI DSSといった業界標準ガイドライン全てに準拠しなければならず、顧客および外部監査機関へ報告して承認をいただく必要があります。これら設計を素のk8sとそのエコシステム群を組み合わせて実現するとなると、考慮事項はさらに膨大になってしまいます。しかし、ECS/Fargateを選択して責任範囲の多くをAWSに委譲することで、コンテナ基盤の設計スコープを最小化することが可能です。
この図は、ECS/Fargateにおける責任共有モデルを示しています。半分以上のカテゴリの運用責任をAWSに委譲することができます。そのため、利用者はコンテナイメージとオーケストレーション設定のみに設計範囲を限定することができ、ホストOS・NW・ストレージといった低レイヤー部分の考慮が不要となります。設計者からすると「マネージドサービスなので、そこはスコープ外です」という魔法の言葉が使用可能になります。有史以来ベンダーが悩んできた部分、飲まざるを得なかったリスクをアウトソースできます。また、コンテナイメージは利用者責任ですが、AL2ベースOSイメージやCorrettoなどのランタイムを利用することができるなら、さらにそのスコープは狭まります。（将来的にはCloud Foundryのようにアプリケーションフレームワークまでもがサポートされていくことを期待せずにはいられません。）
この図はコンテナホストにEC2とFargateを採用した場合の運用コストとそのコスト比率を表しています。コンテナホストの運用をAWSに委譲することで利用者側の負担がどれほどの低減されるかが示されており、直感的にわかりやすい図です。エンタープライズレベルの運用を導入する場合、水中より下のコストスケールは対数グラフで表されると考えられるぐらい膨大になるだろうなと感じました。余程のセキュリティ要件がない限りはマネージドサービスを利用すべきですし、逆張りされないように上記メリットを正しく伝える徹底的な社内ロビイングが重要だろうなとも感じました。
※昨年Fargateに大幅な値下げがあり、AWS Monthly Feesの差は小さくなっています。また、EC2とFargateを起動時間だけにフォーカスしてコストを論じることはナンセンスです。
FSI Lens (AWS Well-Architected)がなぜ有用なのか
「3. 設計に必要な視点の整理」では、何を拠り所に設計すれば良いのかを提起し、FISC安全対策基準をベースにAWS Well-Architectedを組み合わせることが有用だと述べられています。
再掲になりますが、金融サービスでは設計すべてに明確な根拠(拠り所)が必要です。それが説明できないと、有事の際はベンダー側の瑕疵として青天井の責任を負わなければなりません。ベンダーにとって、ガイドラインは自身を守るシェルターとしての役割もあります。金融サービスでは、FISC安全対策基準をベースに、取り扱う業務、アーキテクチャに応じて「PCI DSS」、「NIST SP800-190」などのガイドラインに準拠します。しかし、それらはプラットフォームに依存しないために基準が抽象的です。それらをどう解釈したか、どういう合意形成で推進したかによって、築いたシェルターは鉄にも紙にもなります。そこで、新たな拠り所として期待されているのが、AWS Well-Architectedの金融ワークロードに特化したW-Aである
「FSI Lens (Financial Services Industry Lens)」です。
FSI Lensでは、金融サービスでよくある要件をAWSでどう実現すれば良いのかを様々なサービスシナリオと合わせて、具体的なサービス名、構成例を用いて示しています。今まではAWSのSolution Architect様とのディスカッション議事や、社内事例といった論法で設計するしかなかったのですが、正式なドキュメントであるFSI Lensに準拠することで、AWSサービスを正しく利用する名分を得ることができます。
(これが本当にありがたいのです…ありがとうございます！！)
FSI Lensを設計に落とし込む
「4. ECS/Fargate設計の要所」では、実際に構築されたキャッシュレス決済管理サービスを例に、FSI Lensに準拠した設計の勘所を述べられています。
上図がそのサービスの構成図です。サービスの配置や組合せはよくある構成ですが、通信経路、機密情報保護、コンテナイメージの堅牢化など、疎かにしがちな部分を誠実に対応されており、さすがだなと感じました。
(一方で、進行中のシステム設計に漏れがなくて安心した自分がいました)
詳細を解説するには時間が圧倒的に足りない濃い内容でしたが、以下の講演資料でもまとめられており、合わせて確認されることをお勧めします。
おわりに
マネージドサービスを賞賛する記事になりました。品質 << 敏捷性な業界では積極的に利用すべきだと考えます。しかし、そうでない業界の場合、それらを盲信した利用には反対です。昨年のALBの障害では、2AZに配置する設計(かつスティッキーセッション有効な設定)にすると、単AZ障害時にALBの切り離しができず、復旧を待つしかないような状況になりました。大規模な障害が東京リージョンで毎年のように発生しています。突然、コントロールプレーンに一切のアクセスができなくなったとしても問題ない運用になっていますでしょうか？つい忘れがちですが、マネージドサービスを運用しているのは「人」と「人が作ったシステム」です。委譲した責任は取り返せません。AWSはSLAをもとに時間分の返金に応じるだけです。その額は顧客への賠償責任や、失う信頼と比べるべくもありません。
利用者側でマネージドサービスの仕様を正しく理解し、BCP要件に準じた設計をする意識づけも重要だと感じました。(これは自戒を込めて言いました。)
改めて素晴らしい発表をありがとうございました。
この記事が気に入ったらサポートをしてみませんか？