AWS×Go×コンテナで作る証券プラットフォーム　金融業界におけるクラウド活用のこれから

AWSとGo言語とコンテナによる証券プラットフォーム

石橋淳志氏（以下、石橋）：こんばんは。今日は『AWSとGo言語とコンテナによる証券プラットフォーム』というテーマでお話しします。まずは自己紹介させていただきます。私は石橋といいます。大学在学中にフィナテキストの創業に関わって、かれこれ5年くらいになります。

日頃Go言語を使っていて、terraformをAWSのインフラのプロビジョニングに使っていることもあって、terraform-provider-awsにはいろいろコミットしています。

次に会社紹介をさせていただきます。

フィナテキストはReinvent Finance as a service、金融をサービスとして再発明するをビジョンとしてやっているFinTech企業です。

金融サービスをtoCやBtoBtoCで出すサービス開発をメインとするフィナテキスト。去年パブリックにローンチした、証券システムのBaaSを提供しているスマートプラス。そしてビッグデータの解析をメインとしているナウキャストという会社があり、三位一体やっています。

従来の金融の証券サービスは発注部分からアプリケーションまで完全にバンドルされて、1つの証券会社が一気通貫で出すようなものが多かったです。

最近ではSNSやニュースサイトを見ている人もいれば、企業分析をして投資する人、または株式優待をメインにする人、テクニカルをメインにする人もいます。

入口はいろんなかたちで入ることができ、その中で自分にあったサービス、取引の仕方でできるようになっていければいいなということで、執行部分やバックオフィス部分をバンドリングして、その上のアプリケーションを自由に作れるようにしようというのがBaaS構想です。今日はこちらをメインでお話させていただきます。

3つの特徴

今日はこのBaaSの中で特徴となる部分をいくつか紹介します。

1つは今日のタイトルのとおり、ほぼすべてのサービスをコンテナで稼働させている点。そして2つ目は認証サービスを切り出している点です。

最後に、これは聞きなれない名前かもしれませんが、AWSが専用線だったり、オンプレからネットワークの繋ぎ込み用として出してるDirect Connectというサービスがあります。これによって外接環境の繋ぎ込みを行なっています。

それぞれ1つずつ見ていきます。まずコンテナの部分に関してです。

大枠としてはRoute53、DNSでサブドメインレベルでサービスのネームスペースを切ってまして、ALBに向けています。リクエストはそのALBに集約しており、これがゲートウェイのようになっていて、Host Headerをもとに後ろのターゲットグループ、ECSに振り分けています。そしてそれぞれの中でDockerコンテナが動いています。

こういうサービスがマイクロサービス化した際の問題として、ログの集約があります。そこはawslogsというログドライバを使ってCloudWatchに流しています。また、ECS上でcronの実行も当然ありますので、そこはCloudWatch Eventsによってマネージドで運用しています。

Go言語によるコンテナ運用のいいところ

Go言語によるコンテナ運用のいいところとして、ECSによるオートヒーリングとクラスタのAuto Scaling groupによる構成によって簡単に潰せる環境になっているのが嬉しい点です。

例えば2月にDockerコンテナの脆弱性がありました。サーバー台数としてはだいたい100台くらい動いています。その際には、脆弱性を解消したイメージに更新するのに1日あれば十分でした。

また侵入などがあったとしても、インシデントレスポンスとしてすぐにサービスを隔離してもメインのサービスのアベイラビリティを維持できるのが嬉しいところです。

先ほどのCloudWatch Logsにログを集約するところなんですが、そこはメトリクスフィスターやKinesisを介して、アプリケーションのログを解析して、オンラインにレスポンスできるのが嬉しいポイントです。AWSでいうとexport taskというものがあり、CloudWatch LogsからS3にパーティションを分けて吐き出せるので、あとでAthenaなどで分析できるのもいいところです。

あとcron処理をCloudWatch Eventsでやってると副次的に出てきたのも嬉しい点として、AWSのAPIで今サービス全体として動いているcron jobが何時に何が実行されてみたいなことの一覧化が簡単です。

またGoを使うことでDockerのマルチステージビルドという機能をうまく活用できます。ビルドステージにのみGoの環境があって、そこで作成されたバイナリをランタイムステージの薄いalpineで実行する、といったような感じです。

Goだとこれがほぼテンプレートして書けて、イメージサイズも10MBくらい。ECRだったりプッシュされた状態では、5MBくらいのかなり小さいサイズでキープできているのが嬉しいところです。その、結果プロセスを走らせたり、フェイルオーバーするときのオーバーヘッドもすごく小さくなるので、そのあたりもいいところだと思います。

認証サービスの切り出し

次に認証サービスの切り出しについてです。マイクロサービスとしてサービスがいくつかあります。認証をどう解決しているのかというと、今はCognitoを使ってクライアントにjwtを吐き出して、それを各サービスがデコード、バリデーションして使っています。

認証はCognitoのOpenID Connectで委譲しています。認可のほうは現状内部的に認可サービスをプロトコルとしてはgRPCを使って各サービスから問い合わせてやっています。

なぜgRPCを使っているかと言うと、スキーマドリブンでやりたかったのが一番大きなところです。というのも認可サービスは1つあって、ほとんど今後作っていくサービスやアプリケーションは認可サービスを使うクライアントになります。

その結果、gRPCのスキーマからクライアントコードをジェネレートできるのはすごく嬉しい点なので、gRPCを選定しました。あとは単純に認可のところでパフォーマンスも早いです。

これは現時点ではやってないのですが、Cognitoを使うとCognitoとLambdaだったりで、サーバーレスでパスワードレスでの認証も簡単にできるので、いろいろ遊んでみるとおもしろいかと思います。

ただ、あらゆるサービスでOpenID Connectなどの認証の委譲が適しているかと言うとけっこう微妙です。そこは各自のサービスに要件が合うかどうかを選びながら選択するといいかなと思います。

最後にDirect Connectによる外接環境です。金融だと発注や市場のデータを取ってくるところが、TCP上でHTTPではなく独自の仕様でバイナリストリームを解析してやるみたいなことがけっこうあるんですね。

発注だと一応FIXと呼ばれる、Financial Information eXchangeと言われる発注のプロトコルがあって、注文のやり取りはFIXを用います。その結果専用線での接続を余儀なくされる場合があります。ただなんとかそこをAWS上でやりたかったので、今回はDirect Connectを使ってやっています。

ほかにも金融系だとSFTPを使うことがありますが、ここは最近出たAWS Transferが助かるという印象があるんですが、現状ちょっと高いので、なかなか導入しきれていません。

最近なのですが、金融機関相手でもS3でのファイル連携をやってもいいところも出てきていて、そこは嬉しいです。AWSでPrivate LinkというほかのAWSアカウントと実際にVPC内部にネットワークインターフェイスがあるように接続できるサービスがあります。それが将来的にできるとDirect Connectを外すことができます。

嬉しい部分がある一方で、AWSやGCPがインターネットっぽくなっていくので果たしてそれ自体はどうなのか？　というのはさておき。

金融業界におけるクラウドのこれから

最後にまとめです。コンテナオーケストレーションはとにかくいいです。ここに関しては正直個人的にはとにかく脳死的にコンテナオーケストレーションでどう運用するかを考えたほうがいいかなと思います。

というのも、コンテナ化することによってある程度ステートレスにアプリケーションを作る必要が出てきます。そこでアプリケーションをどう作っていくかというロジックで制約をかけて、全体としては技術負債をあまり生まないかたちになるのかなと思います。

あとは、認証・認可のところはCognitoなどを使うとサーバーレスでいろいろできておもしろいんですが、ここはサービスの実際に作る要件に合わせて選択したほうがいいと思います。

また、ここは大局的には微妙なのかもしれませんが、個人的には局所的にAWSやGCPの導入がいろいろな金融機関で進んで、クラウド上での接続が盛んにできるようになるといいなと思います。

最後に、フィナテキストは金融に興味のあるエンジニアの方を常に募集しています。このあとの懇親会でも興味ある方はぜひ声をかけてください。以上です。ありがとうございました。

（会場拍手）

ログの運用について

司会者：ありがとうございました。続いて質疑応答に移りたいと思います。どなたか質問のある方はいらっしゃいますか？

（会場挙手）

質問者1：お話ありがとうございました。最初にS3でログを溜めておけばAthenaでも集計できて便利、みたいな話をされていたと思うんですが、実際にAthenaでなにか分析や集計をされているかというのと、S3のフォーマットに何を選んでいらっしゃるか教えていただけたらと思います。

石橋：現状、基本的にJSONでとりあえず出しとけという感じです。現状Athenaで分析とまではなかなかいっていなくて、どちらかというと障害やデータ不整合、エラーがあったときに過去分を遡れるような感じで使っています。

最近だとCloudWatch Logsのほうにメトリクスもついたので、直近分に関してはそちらで引くとすごく楽です。あとは統計データの可視化もできるのもすごく便利ですね。

質問者1：ありがとうございます。

データストアの使い分け

司会者：ほかに質問ある方いらっしゃいますでしょうか？

（会場挙手）

質問者2：お話ありがとうございます。途中から来たので最初に話していたかもしれませんが、バックエンドってどんな感じになっているんでしょうか？

石橋：バックエンドというのはどのへんをイメージされていますか？

質問者2：あ、ごめんなさい。データストアという意味合いです。

石橋：基本AuroraかDynamoですね。

質問者2：Dynamoはトランザクションが付く前はどうやって使い分けていたのでしょうか？

石橋：そういう意味で言うとトランザクションがほしいところはAuroraを使っています。ほぼ1サービス1テーブルでいいところでは、気軽に作れるのでDynamoを使ってます。

あとは市場からのプライスデータなどはすごい量が来ます。朝9時頭には秒間数万件みたいなやつはDynamoの、とりあえずお金を払えばスケールを上げられることをうまく使いつつ、アプリケーションまである程度シャーディングはコントロールしてやっている感じです。

質問者2：ありがとうございます。

司会者：ありがとうございます。他にいかがでしょうか？

（会場挙手）

質問者3：Cognitoを使っていることでしたが、Cognitoを使っているサービスってあまり見ないので、ちょっとめずらしいなと思ったんですけれども。

この中でも、認証でCognitoを使いつつ、認可のサービスでは独自のサービスを用意しているということで、Cognitoを使うときの、これはマネージドで嬉しいけれども、なにかつらみがありましたら教えてください。

石橋：Cognitoでは、作った後に変更できないパラメータがけっこうあります。例えばユーザーネームやEmailといった属性があるんですが、1回作ったのちにユーザーネームないしEmailでのログインも可能にするみたいな変更ができなかったりします。

将来的にはできるようになるのかもしれませんが、そこを将来別のかたちでのログインをやりたいときには困る可能性はあるかもしれません。

質問者3：なるほど。参考になりました。ありがとうございます。

司会者：石橋さんありがとうございました。拍手をお願いします。

（会場拍手）