Docker をフル活用して金融業界のシビアなパフォーマンス、セキュリティ要件に対応している株式会社Finatext石橋さんに、難しいポイントやアーキテクチャ上の工夫を伺いました – 後編

みなさんこんにちは、スタートアップソリューションアーキテクトの塚田（Twitter: @akitsukada）です。前編に続き、株式会社Finatext の石橋さんにお話を伺っていきます！

後編では、アーキテクチャや技術の選定をどのように考えてきたか、FinTech スタートアップとして不可避であるセキュリティ・コンプライアンスの高い要求をいかに合理的に対応してきたかなどをより深くお伺いします。

前編
- Finatext、スマートプラスと石橋さんについて
- 会社とチームが大きくなるにつれて生じた、創業期からの変化
- FinTech、証券業界特有の技術要件とは？市場に合わせたピークタイムとアクセス特性
後編（この記事）
- （続き）FinTech、証券業界特有の技術要件とは？市場に合わせたピークタイムとアクセス特性
- アーキテクチャと技術の選定について – Amazon ECS と AWS Lambda の使い方
- 金融業界に身を置くFinTechスタートアップとして、セキュリティ＆コンプライアンスについて
- これまでとこれから、および読者へのメッセージ

では、いってみましょう！

FinTech、証券業界特有の技術要件とは？市場に合わせたピークタイムとアクセス特性

— （続き）Amazon DynamoDBに1TB/月の新規データ書き込み、少なくない量ですね。例えば DynamoDB のデータ容量やキャパシティユニット費用など、コスト面で工夫などはされていますか？

そうですね。当初は全てのデータを DynamoDB 上に残していましたが、今はほぼ半年分を残して古いデータは Amazon S3 に逃がして DynamoDB のストレージ容量を節約しています。この処理は、最初は DynamoDB の TTL 機能を利用して実装することを考えたのですが、検討の結果、TTL でなくバッチ処理で Delete して S3 に移すようにしています。

経緯としては、TTL は仕様上発動するタイミングが厳密でなく最大 48 時間以内に削除される ※ とのことだったので、仮に Expired Time を夜間にセットしたとしても日中に TTL による Delete が走る可能性があります。それをちゃんとキャッチするためには常に Lambda がトリガーされるように設定しておく必要がありますよね。そうすると、実際に DynamoDB Streams からの Lambda で処理したいのは DELETE 分だけなんだけど、BatchWriteItem がガシガシ走っている日中は INSERT などの分も Lambda、いわば “空打ち” の Lambda がバンバン起動されることになります。その “空打ち” 分の起動時間を合計するとけっこう大きくなってしまい、けっこうコストがかさむ…うーん、どうしようかな。と。

（※ ご参考：DynamoDB の TTL 機能についてはこちらの資料48ページをご覧ください。）

AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern

そこで代わりに、明示的に土日にバッチ処理で Delete し、そのまま DynamoDB Streams → AWS Lambda → Amazon Kinesis Firehose → Amazon S3 に上げて過去分を保存するようにしました。こちらの形式だと、DynamoDB の Capacity Unit を消費しない TTL に比べて Delete 処理分のコストやバッチの実装の必要性は生じるのですが、そこは TTL で処理したときのコストと比較して決定した、という流れですね。

— なるほど。これだけ負荷の増減タイミングがはっきりしているサービス特性だと、スケーラビリティを確保する手段としては負荷ベースの Auto Scaling だけでなく、スケールアウトのタイミングをスケジューリングしたりもしていますか？

はい。朝の8時から動く必要があるシステムについては、8時前にAWS Lambdaを使って一斉にスケールアウトさせています。9時前にも同様ですね。必要なくなったら落としたりしつつ、うまくコストダウンとパフォーマンスの要件を満たせるようにしています。

今後は市場の動き方だったりユーザーの動向だったり、より有機的な要因を掴んでプレディクションを行い、より滑らかにスケーリングさせていきたいと考えています。そこにしっかりと取り組んでいこうとすると、将来的には機械学習を手がけるエンジニアを今よりもっと増やしていくことになるかと思います。

— AWS Auto Scaling が提供している予測スケーリングではなくて、より業界事情を反映した独自の指標を持って需要を予測していくということですね。面白いですね！

そうですね。例えば政治的なイベントがあるときは市場の売買がより活発になったりするんですが、そうした外部環境もしっかり加味していければと思います。長いタームで学習し、バッファをうまく持たせながらも最低ラインのような部分をうまくプレディクションしていきたいですね。

アーキテクチャと技術の選定について – Amazon ECS と AWS Lambda の使い方

— ECS と Lambda についてももう少しお聞きします。スマートプラスのシステムは ECS上に複数サービスを稼働させる、いわゆる Microservices 的なシステムアーキテクチャ手法を割と初期から採っていますよね。ただ、必ずしも組織とシステム構造とが一致していない点もあったり、初期段階からシンプルな Monolith でなくしっかりサービスを分割して設計されていたり、といったところが特徴的なのかなと思っています。私にもかなり初期の段階からご相談いただき、あれこれディスカッションした記憶があります（その節はありがとうございました）。改めて読者の方に、スマートプラスのシステムを作り始めるとき、どういう判断でアーキテクチャを決めていったのかをご紹介いただけませんか？

まずサービスに必要な機能をモデル化していったとき、責務や利用したい技術が明確に異なる箇所が複数あったんですよね。先ほど話していた最新株価配信（前編参照）についても QUICK と接続するシステム、publish するシステム、クライアントと WebSocket で接続されるシステムがあったり。証券会社に接続するところでは、オンラインで証券取引を行う際のスタンダードなプロトコルであるFIX（Financial-Information-eXchange）をしゃべるサーバが必要だったり。いわゆるバックオフィスのサービスとつなぎこむところ、データを取り込むところがあったり。あと、各種の権限制御については請求に関連する複雑な要件があったので、サービスとして一つにまとめていたりします。

実際のところ、Microservices をバリバリ志向したというよりは「ここを分けておくと作りやすそう」という単位で分割していった感じですね。扱うデータや求められるコアな機能と果たすべき業務範囲、パフォーマンスやセキュリティの要求レベル、その後の機能拡張の生じ方などが違ってくる単位で分けていきました。

— 「果たすべき業務範囲」「扱うデータや求められるコアな機能」でいうと、厳密に同じではないかもですが DDD 的な意味でのドメイン単位で分割したとも言える気がしますね。DDD と Microservices も関係が深いところではありますが。利用されている技術の面ではAmazon ECS をフル活用されているのですが、そもそも Docker を全面的に採用し、活用しているのはなぜですか？

Docker コンテナを使いやすかった一つ目の要因として、Go 言語をメインに採用したのは大きかったです。Docker コンテナの設定自体を記述するのに Go テンプレートが利用できるので、全体として導入しやすかった。あともちろん、コンテナベースにすることで Amazon EC2上で動かすよりも、ある程度ステートレスなアプリケーションとして作らざるを得なくなる点はいいですね。結果として、拡張性、可搬性、可用性の向上につながっていると思います。ECS 上では、先ほど紹介した構成図にある以外にも、長時間走らせる必要のあるプロセスを多くサービスとして動かしていますね。

— ECS、Docker を活用されていることがよくわかりました。一方、AWS Lambda もフロントに関わるところでお使いだったと思います。Lambda ではどんな処理を行っていますか？

そうですね。たとえば、注文に対する約定情報の処理に使っています。取引所に注文を投げると結果は常に非同期で、具体的には実際の値段がついた後に返ってくるのですが、それを Amazon Kinesis Data Streams 経由でLambda で受け取って処理しています。

処理の順序に沿って図の上半分、左側から、注文の処理について説明します。まずクライアントアプリからの注文リクエストを Amazon SQS にエンキューするサービスがあります。そのキューを見張っている ECS サービスが居て、キューからジョブを取り出して FIX プロトコルで証券会社に注文情報を送ります。このとき注文の順序を担保すること、重複を排除することが重要な要件なのですが、当初 SQS の FIFO キューは東京リージョンに来ていなかったため、自前で DynamoDB を使ってメタデータを管理しながら頑張ってアプリで実装していました。が、そうこうしているうちに FIFO キューが東京リージョンでもローンチされたためすぐに使い始めました。便利ですね、FIFO。

そして約定の処理を行うのは図の下半分、右側からです。FIX を通じて約定情報を ECS 上の FIX 担当コンテナが受け取り、DynamoDB に書き込みつつ Kinesis にデータを Put する。それで Lambda が起動して、DynamoDB から情報を読みながらプッシュ通知などの必要なアクションを実行する、というものですね。今後この約定後のアクションのパターンが増えていくと思いますが、必要になったら Lambda の処理を拡張していけば済むようになっています。

金融業界に身を置くFinTechスタートアップとして、セキュリティ＆コンプライアンスについて

— 次に、金融業界におけるスタートアップ、いわゆるFinTech企業としての事情をお伺いしたいと思います。Finatext 石橋さん、田島さんといえば、6月に開催されたAWS Summit Tokyo 2019 にもご登壇いただき、その先進的なセキュリティアプローチを詳しくお話いただきました。

AWSにおけるクラウドネイティブでセキュアな証券システムの運用 / aws-summit-tokyo-2019-l2-03-finatext

（AWS Summit Tokyo 2019 における講演資料。石橋さんと田島さんにより、特にセキュリティ面について深堀りされている必見資料です。）

実際のところを聞きたいのですが、証券という規制業界の中で、セキュリティ面やコンプライアンスにおいて苦労を感じることはありませんか？

組織体制の部分でガバナンスを敷くことが結構多いですね。例えば Finatext であれば全員が一丸となってサービスを作っていけるのですが、スマートプラスの場合はまず証券会社として果たすべき責務がありますし、社内での情報共有という面を見ても、必要以上に部署間で情報を共有しないなどのルールが設定されています。そうなると、自分の情報は人には自然に伝わらないし、人からの情報も勝手に自分のところに入ってくるわけではなくなります。そこは会社として、情報の取り扱いに対して強い意識を持っていますね。

そういった統制によって様々な情報と開発メンバーが物理的に遠くなることで、実際のサービス開発にも影響が出てきます。例えばシステムに関する情報で、「どのような構成で作っているのか」「どういうセキュリティ要件を満たしているのか」といった内容を、いかに他の開発者に分かる形にして共有するか。あとは、「全てクラウド上に作っている」という部分自体が証券会社としては新しいことなので、関係者にどうやってそれを認識し、理解してもらえるのか。そういった部分にも配慮してきました。

— Startup SA として他の FinTech スタートアップの皆さんとも話をさせていただいていると、長く金融業界で経験を積んできたベテランな方をガバナンス担当者として招聘する、あるいはそういった方が経営など事業の根幹に関わっているのがパターンなように思います。それはやはり、実際の現場経験、肌感覚を持っている人材が関わる必要があるからだと思うのですが。スマートプラスにはどのようなタレントがいるのでしょうか。

スマートプラスはもともと、基本的に知見が豊富な証券業界出身の人が中心なんです。だけど、旧来のやり方を踏襲してきたというよりは、新しい技術やクラウドで対応方法を再発明しながらここまできた、と言えます。例えば、従来求められてきたセキュリティ要件や慣習は、まだ十分にクラウドが考慮されたものではなかったりするのですが、それに対して僕たちは「今の技術を使えばこの要件はこう整理、対応できるよね」と解釈し直して、合理的な対応方法を取ろうとします。そういった要件は、抽象的、概念的に書かれることが多いので、解釈の余地が大きいんですよね。なので、「自分たちで作っているものをどう解釈するのか」が大切です。

— 曖昧な要件に対して、「こうすれば現代の最適解になるのではないか」と解釈するわけですね。実際にそれを実装した例としてはどのようなものがあるんですか？

例えば、Infrastructure as Code の実践や AWS Organizations による組織統制などですね。

監査の要件の中にはリソースの管理だったり、各種の棚卸しが必要なものがあったりします。それに対して Infrastructure as Code が実践されていれば — 具体的には Terraform で構成管理していますが、すでに Code 上でリソースの状況は明文化され、しかも Git の履歴付きで管理・可視化できていると言えますよね。バッチ処理や cron的な定期実行処理も、Amazon CloudWatch Events で起動する Lambda ファンクションや ECS の Task として定義してあるので、やはり Code 上で本番環境の状況が把握できます。

AWS Organizations は、組織とアカウントの管理に活用しています。当初は組織ごとに独立した AWS アカウントがあったこともあるんですが、今では Finatext ホールディングスで持っているアカウントで Organization を作り、他のアカウントを配下に入れています。それぞれのアカウントには SCP（Service Control Policies）で操作可能な範囲を設定し、例えば Amazon RDS のバックアップ削除操作や、普通やる必要がないであろう delete 系の操作を制限するなどコントロールしています。

関連各社で AWS アカウントも増えてきましたが、それぞれの AWS CloudTrail ログや AWS Config によるリソースの監視、VPC Flow Logs や ELB のログは集約管理用のアカウントに集めて一括チェックしていたり、万が一各アカウントに侵入されても大切なログは守れるようにアカウントを分離したり、工夫しています。あと、集約用アカウントにはより Strict な監視や権限制御を実装するとか。

他にも、AWS は API が豊富なので、先ほどの定期処理の定義などはいつでも List* や Describe* 系の API で一覧や状況を確認することができます。もし EC2 上に crontab で定期処理を定義していたらこれはできないですよね。

この辺りのセキュリティ、コンプライアンスの考え方、自動化、合理的な実装については AWS の SA さんともよく議論させてもらっていますし、Well-Architected フレームワークや FinTech リファレンス・アーキテクチャーに基づいたレビューなどはとても役に立ちました。

— そういった金融文脈の事情、コンプライアンス要件に直面してきたエンジニアは、スタートアップの中にはまだ少ないのではないかと思います。エンジニアのボリュームゾーンとしては、いわゆるWeb系出身のエンジニアの方が多かったり、とか。最初から FinTech の業界に身を置く石橋さんとしては、こういう詳細なコンプライアンス要件をぶっちゃけめんどくさいと感じる瞬間はありますか？

いや、まぁ頑張ってますが（笑）、めんどくさいとは思わないです。実際、そういった要件をいかに最新技術でクリアしていくかといった面は楽しいですよ。証券業界の経験豊富な、頼りになる仲間も多いですし。

終始なごやかにお話を伺いました

これまでとこれから、および読者へのメッセージ

— これまでやってきた中で、何か読者の皆さんに共有できる失敗談や学びなどあれば教えてください。

そうですね。今にして思えば、開発初期の段階からもうちょっと設計と考慮をしておくべき箇所もあったなと思います。たとえばデータ分析基盤です。機能性を実現することが優先される開発の初期開発だとデータ分析をする要件自体がまだなかったりしますよね。でも、今になって、たとえばマーケターから「こういうデータがほしい」と言われたときに、そのデータがなかなかすぐに出せなかったりすることもあり、結果ビジネスのスピードに影響を与えてしまったりもします。データの設計だったりログの収集方法だったり、可視化や分析の仕方だったり。今そこは整備していて、Amazon Kinesis を使ったログ分析基盤を構築しています。

— では、今後についても教えてください。どういったところにチャレンジしていく予定がありますか？開発面でも、ビジネス面でも結構です。

サービス間のインタフェース、通信プロトコルをより柔軟にしていきたいです。今は主に http で、一部 gRPC を使ってサービス間でやりとりしているのですが、今後はユースケースに合わせて gRPC だったり http だったり、メリットが出るように選べるようにしていこうと思っています。

その先としては、分析基盤に乗っける可視化・分析用のアプリケーションを作ることもしたいですし、さらにデータがしっかり活用できる状況になってきたら、ユーザーさんにメインの取引ツールとして使うサービスをサジェストしていくようなこともやってみたいと考えています。冒頭の紹介で言ったように、ユーザーさんによって株への取り組み方や目的は様々なはずなんですよね。例えば積立メインのサービスがあったり、よりテクニカルなサービスがあったり、ユーザー特性によって適したサービスがあっていいはず。で、最初試しにどれかを使ってみてもらって、その後さらにその人にあったツールをサジェストする、レコメンドする感じですね。

— ありがとうございます。最後に、この Startup ブログの主な読者はスタートアップにいるエンジニア、またはスタートアップに興味のあるエンジニアの方です。読者へのメッセージをお願いします。

メッセージ。メッセージか。

ええと、FinTech の領域は外部接続（社外のシステム、例えばプライス流してくれる QUICK、注文をやりとりする取引所との接続など）の要件なども多い中、実際に触れる技術やトピックのカバー範囲や時代的な幅が結構広いのが特徴だと思うんです。古い技術から新しい技術まで、幅広く関係してくるという。既存の社会や外部システムとのインターフェイスを保ちつつ、より合理的に新しい技術を使ってどう再発明していくのかというところは、エンジニアリングの価値を発揮できる余地がとても多く、面白いです。企画や新しいプラクティスの提供を楽しめる人にとっては、FinTech はうってつけの業界だと思います！また証券会社を運営しつつ、そのコアシステムも内製で開発できるのはうちのユニークなところでもあります。僕らと一緒に金融を再発明してみたい、と少しでも思った方はぜひ一度ご連絡ください！

— お話を伺って、FinTech は大いにチャレンジのしがいがある領域であり、かつ Finatext がいかに高い技術力を駆使しているかがよく分かりました。どうもありがとうございました！

Finatext 石橋さんのインタビューはここまでです。前後編でお届けしてきましたが、いかがでしたか？

時間帯ごとのアクセス特性や外部との接続、セキュリティ・コンプライアンス面など業界ならではの要件に対し、Docker やセキュリティオートメーションといったモダンなアプローチでいかに立ち向かっていらっしゃるか。Finatext・スマートプラス、そして石橋さんの魅力が、スタートアップなエンジニアの皆さんに少しでも伝わっていれば嬉しいです。

改めて、石橋さんありがとうございました！

このブログの著者

塚田朗弘（Akihiro Tsukada）
スタートアップソリューションアーキテクト。AWS FinTech リファレンス・アーキテクチャーの作者の一人。好きなサービスは AWS Amplify、AWS AppSync、Amazon Pinpoint、Chalice。趣味は頭を触ってくる子供と遊ぶこと。

AWS Startup ブログ