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がインターネットっぽくなっていくので果たしてそれ自体はどうなのか？　というのはさておき。