AWS Startup ブログ

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

皆さんこんにちは！スタートアップソリューションアーキテクトの塚田（Twitter: @akitsukada）です。今日は、注目の FinTech 企業 株式会社Finatext において創業期から設計・開発をリードしている石橋さんにお話を聞いてきました。

石橋さんはAWS Summit Tokyo 2018, 2019、AWS Dev Day Tokyo 2018 等で登壇するなど、AWS に関する深い知見をお持ちです。

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

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

そんな石橋さんたちは、証券取引を扱うシステムに求められるパフォーマンス特性やトラディッショナルな技術要素、あるいは金融業界で必要になるセキュリティ・コンプライアンス要件を、AWS の中でもモダンなサービスを駆使して実現されています。

FinTech 業界の皆さんも、Dockerに興味がある方も、ぜひ読んでみてください！まずは前編をお届けします。

目次

  • 前編（この記事）

    • Finatext、スマートプラスと石橋さんについて
    • 会社とチームが大きくなるにつれて生じた、創業期からの変化
    • FinTech、証券業界特有の技術要件とは？市場に合わせたピークタイムとアクセス特性（続く）

  • 後編

    • （続き）FinTech、証券業界特有の技術要件とは？市場に合わせたピークタイムとアクセス特性
    • アーキテクチャと技術の選定について – Amazon ECS と AWS Lambda の使い方
    • 金融業界に身を置くFinTechスタートアップとして、セキュリティ＆コンプライアンスについて
    • これまでとこれから、および読者へのメッセージ

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

Finatext、スマートプラスと石橋さんについて

— まず石橋さんは、株式会社Finatextと株式会社スマートプラス、2つの会社に関わられていると思います。その2つの会社の関係について教えてください。

Finatextは「金融を再発明する」というビジョンに掲げている会社で、創業して5年ほど経つスタートアップです。BtoBやBtoC向けに、「金融をいかに楽しくかつおもしろくユーザーさんに伝えるか」を日々考えながら取り組んでいます。

一方スマートプラスは、Finatextのグループ会社にあたる会社で、「BaaS（Brokerage as a Service）」を展開しています。

“まったく新しい証券サービス BaaS（バース：Brokerage as a Service）は、スマートプラスが提供する証券ビジネスプラットフォームです。 BaaSにより非金融系の企業が証券サービスを始める際、開発コストが低減され、多様な証券サービスが生み出されます。”
〜 スマートプラス Web サイトより

株って目的や手段も人それぞれだし、色々な人がやってるんですよね。株価や市場、銘柄の情報収集に SNS を活用する人もいれば、株主優待目当ての人だっています。それに、これから株を始めてみたいという初心者の方もいれば、株取引に長年の経験と知見がある上級者だっていますよね。スマートプラスでは、そういった色んな目的や視点を持った多様なユーザーさんがどんな入り口から入ってきても、BaaS上で自分にあった取引の仕方を見つけられるようなサービス ”STREAM” を提供しています。コンピュータでいうと OS に当たる部分が BaaS と言えると思います。

— 石橋さんはいつ、なぜFinatextにジョインされたんですか？

Finatext共同創業者の戸田（株式会社Finatextホールディングス取締役/Co-Founder 経済学博士 戸田 真史氏）とつながりがあり、また大学では金融工学を専攻していたこともあって、創業時にインターンとして入社しました。当時は何もサービスがない状態でした。最初は iOS アプリの開発を担当するところから始まり、その後サーバーサイドも含め都度必要なことをやってきました。

— 今の開発体制について教えてください。

今はFinatextの国内チームとして13名ほどのエンジニアがいます。また、ビッグデータ技術で経済を解析するグループ会社である株式会社ナウキャストにデータサイエンティストが7名、またベトナムの会社 Teqnologicalの開発チームに20名ほどのエンジニアが在籍しています。

実はスマートプラスには基本的には開発者は所属していなくて、Finatextの開発メンバーが委託でやっているような形態になってます。オフィスの場所は同じフロアなので、緊密に連携しながら開発を進めています。

プロダクトごとに担当するチームがあり、具体的な開発の仕方については基本的にはそれぞれのチームに任されています。

会社とチームが大きくなるにつれて生じた、創業期からの変化

— まさに今、人数が増えてきているところなんですね。開発チームをプロダクトごとに持ち、さらに人数も増えてくると、チームを超えた開発組織全体に通じるルールや基準のようなものが必要になってきたりしませんか？また、チーム間でのナレッジシェアなどはどんな風に行っていますか？

厳密に決めている規約のようなものはありません。新卒メンバー含め新しく入ってきた人、ベテランの人、それぞれの社員が見つけてくるプラクティスを全員で共有しつつ、プロダクトごとに最適なプラクティスを当てはめているような感じです。

あとは、社内で誰が何に詳しいのかは分かっているので、何かわからないことがあったときは、状況に応じて助け合ったりもします。

— 新卒メンバーの話がでましたが、スタートアップにおいて、新卒メンバーをいつから採用するかは結構興味深い話題だと思います。採用することはできても、育成はできるのか、とか。Finatextでは、いつから新卒社員を採用しているんですか？

新卒といっても、世間一般でいう新卒一括採用のようなフローが明確にあるわけではないですね。事前にインターンとして関わってくれているメンバーが、そのまま新卒として入社するような感じです。新卒メンバーは高いポテンシャルを持っている人が多いと思いますね。

— 新卒メンバーがポテンシャル高い感覚、とても分かります。2018年にアマゾン ウェブ サービス ジャパンに新卒入社した SA 達も、現在バリバリ成果を出しています（Amazonブログ参照）。

ただ、自分自身がインターンだったり、新卒だったりしたときを思い返すと、会社の状況が変わってきているなと思います。自分の頃はまさに ”0-1” で、やることは何でも自分で見つけて、手当たり次第取り組むことができました。今はその時とは会社のフェーズも変わり、自分のような古株のエンジニアも出てきて、少しずつメンバーとしての仕事の仕方も変わってきているのかなと思っていて。彼らをどういう仕事にどう起用していくか、どう成長機会を与えていくかを最近考えています。責任のある仕事を与えつつ、後ろからしれっとサポートしながら、若手にどんどん成長していってもらいたいですね。

— まさに石橋さんは創業当時から在籍している古株、ベテランエンジニアですよね。現在では、石橋さんは会社の中ではどのような役割を担っているエンジニアなのでしょうか？

創業当初から、会社やサービスが大きくなるにつれて必要になる技術をどんどんキャッチアップしながら、自分でガンガン実装するような動き方をしてきました。だけど人数も多くなってきて、自分自身の役割も変わってきていると思います。直近では、社内に点在するプラクティスをうまくまとめて、エンジニア間で広めるような仕組みづくりをよく考えています。

— より組織的な動き、チームとしての成果が求められるようになってきたということでしょうか。「プラクティスを広める」とは、具体的にはどうやっているのですか？

たとえば夕会をやるとき、「今日はこういうことやりました」など、”やったこと” を共有する会社も多いのではないかと思います。うちの場合は、”やったこと” から何を学んだのかも報告するようにしています。それは例えばその日取り組んだ開発タスク中に新しく知ったことだったり、ちょっとしたTipsだったり。これは各エンジニアがその日使った時間をシェアしあうことにつながっていて、そこから気づきや知識の広がりが生まれたりします。

あとは、「逆質問的な社内勉強会」というのも開催しています。普通は勉強会というと発表者がいて、その人がネタや資料を用意して、参加者は聴衆として参加して…といった形式が一般的だと思いますが、それだとどうしても特定の人に負担が集中したり、インタラクティブになりにくかったりします。そうではなく、逆質問的な社内勉強会では、聞きたいこと・分からないことがある人がそれを質問として勉強会の場で共有して、答えられる知見を持った人が答えるんです。こういう勉強会をやることで議論がより発展しやすく、参加するのに敷居も低くなり、ナレッジシェアリングが円滑になります。さらに、「この人はこんなことができるんだ」ということが体験として得やすくなります。

自分はそうやって場を用意して、色んなバックグラウンドを持つメンバーのハブになるようなことをやっています。

一方でもちろん、今でも一人のエンジニアとしてバリバリ開発もしていますよ。

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

— ここからはもう少し技術的なことや、業界ならではの事情などもお伺いしていきたいと思います。まず、Finatext とスマートプラスというFinTech領域、そして証券サービスならではの技術的な特性や要件の難しさがあれば教えていただけますか？

まず株式市場に携わってすごく特徴的だなと感じるのが、毎日の取引などのスケジュールがしっかり決まっていることです。一般的なWebサービスだと、原則24時間365日ゼロダウンタイムが求められたり、メンテナンスタイムも設けにくかったりすることが多いと思います。それに対して、株だと市場が開くタイミングは明確にきまっているため、ユーザーの行動スケジュール、つまりはシステム負荷のパターンなんかもそれに沿ったものになってきます。これによって、例えば市場が閉まっている日曜の夜にシステムを停止してメンテナンスを入れることがそこまでデメリットにならない一方、場が開いている時間帯に万が一サービスがダウンしてしまったら影響はとても大きなものになる怖さもあります。

つまり、ピークとアイドルのタイミングが極端にはっきりしているんです。それに対してパフォーマンスの要件を満たしつつ、全体としていかにコストを削減できるかなどは工夫のしどころであり、まさにクラウドの柔軟なスケーラビリティといった特性を活かせるところでもあります。

— 確かに、必要のない時間帯はサーバーを落としておく、ピークタイムには必要なだけサーバーを立てる、という使い方ができるのはクラウドの代表的なメリットですね。具体的には、株式市場のイベントに沿ったシステムの一日の流れってどういう感じなのですか？例えば、朝の9時に市場が開く前後とかはアクセスがスパイクしていそうなイメージがありますが。

そうですね。確かに市場が開くのは午前9時であってそこも重要なポイントなのですが、実はその前に午前8時から注文の受付がはじまります（実際の約定=売買成立が9時以降）。この8時のタイミングでは、一気に大量の注文受付、Writeアクセスが入ってきます。

その次、市場が開く午前9時は注文の結果や最新情報を確認するReadアクセスのピークになりがちですし、受け付けておいた注文に対する約定が次々と市場から返ってきたりもします。同様に、前場（ぜんば）が閉まる11時30分、後場（ごば）が開閉する12時30分と15時などのタイミングがピークタイムになります。

そして後場が15時に閉まってからも、バックエンドシステムとの連携やファイルベースのバッチ処理など、16時までにやらなければいけないことも多いです。このタイムリミットは後ろに伸ばすことはできないので、今後さらにサービスがスケールしてバッチ連携する先や処理量がより増えてきたときに、ちゃんと時間内で完了できるような仕組みになっているのか、しておけるのか。そこに対しては、技術的に十分に考慮しておく必要があります。

— アプリ “STREAM” では、最新株価をリアルタイムで配信する機能があると思います。株価の配信というと、素早い売買の判断を左右するためシステムにはシビアにリアルタイム要件を求められる、という怖いイメージが私にはあるのですが。STREAM でもやはりそういう要求があるんでしょうか？どういうアーキテクチャでそれを実現しているのでしょう？

はい、QUICK から株価を取得してクライアントアプリに情報を流す、プライス関連のシステムがありますね。こんな構成になっています。

図の右側から追って行くと、まず ”QUICK からの株価受け取り Service” では、AWS Direct Connect による専用線接続を通じて Amazon ECS の Service から QUICK に接続しています。ここは TCP Socket で情報を受け取るのですが、パフォーマンスアップのため銘柄を３つにシャーディングしているため、ECS 上ではそれに対応する３つの Task（Docker コンテナ）が起動し、TCP コネクションを張りっぱなしにしています。また、受け取った情報は Shift JIS だったり zip で固められたりしているので、後続の処理に流す前にそれらのデータフォーマットを変換するなどしています。この Serviceでは DB をいじるなど多くのことはせず、QUICK からデータを受け取り、整形して “フロントへの配信 Service” の Network Load Balancer (NLB) に流す責務だけに集中させています。

次にその ”フロントへの配信 Service” では、だいたい数十個の Task が動いています。この Service への Input は Internal NLB を通じて受け取る株価情報、Output はリアルタイム配信用の PubSub で使っている ElastiCache for Redis への publish、delay 配信用の Amazon DynamoDB への書き込みになります。ここではいくつか工夫があるのですが、まず ECS は Host モードで動かしていて、1 Task / 1 Hostで動かしています。これは各インスタンスのネットワーク性能を最大限に活かすためにチューニングしていった結果それが最適になったのと、1つのホスト上に乗るプロセスをシンプルにして管理しやすくしたことによります。

そこから Redis には、株価のリアルタイム配信のために最新情報を受け取り次第 publish しています。Redis に subscribe している “クライアントアプリへのリアルタイム配信Service“もいて、新着情報を受け取り次第 WebSocket でつながっているクライアントアプリにメッセージを送り、アプリ側で画面を更新します。WebSocket のロードバランシングには Application Load Balancer（ALB）を使っていますね。

一方 DynamoDB には、受け取った “板” の変化をミリ秒単位の時系列で書き込んでいます。時系列で書き込んでいるのは、”STREAM” では未登録ユーザーには20分の時間差をつけて株価を配信するという仕様があり、それを実現するために必要なデータ形式だからですね。こちらは、”クライアントアプリへの20分 delay 配信 Service“ が、リクエストの都度 DynamoDB からデータをGetして返しています。

この DynamoDB に書き込む処理も、最初はナイーブにデータを受け取った都度書き込むようにしていたのですが、今は各コンテナ上でごく短時間だけバッファした上で、バルクで書き込んでいます。これは、都度書き込みすることで生じていた DynamoDB へのアクセスで生じる HTTP コネクションのオーバーヘッドや File Descriptor が limit に達する問題を抑えつつ、QUICK からのデータ配信量や頻度とのバランスを取って過不足がないようにチューニングした結果です。この DynamoDB への書き込みは結構重めで、ECS は9時の書き込み処理に必要な Task 量にスケールしてあり、基本的に日中は下げられません。DynamoDB のWCU（Write Capacity Unit）は 30,000 にプロビジョンしてあり、一ヶ月にだいたい 1TB の新規データ量が書き込まれます。

株取引の裏側を興味深く教えてもらっている図

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

（後編に続く）

ここまでが前編となります。いかがでしたか？
”0-1” のフェーズからグロースフェーズまでエンジニアリング面をリードしてきた石橋さんの様子、Amazon ECS を使いこなして証券取引というシビアなワークロードを実装されているアグレッシブなシステムアーキテクチャ、ワクワクしますね。

後編では引き続き技術面を中心に、サービスの非常にコアな部分である注文・約定処理の解説、そして技術選定やセキュリティ・コンプライアンスの考え方を伺います。

後編も数日以内に公開予定ですので、 Stay Tuned でお願いしますmm
→ 2019/09/06 後編公開しました！

このブログの著者

塚田 朗弘（Akihiro Tsukada）

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