AWS SUMMIT TOKYO 2018にチーフサーバーエンジニアの石橋が登壇しました

石橋の自己紹介

株式会社Finatextの石橋淳志
Finatextは2013年に設立し、モバイルを中心に金融サービスを展開しています。
2016年にはナウキャストという金融ビッグデータ解析の会社をM&Aしました。
現在は証券会社を立ち上げようと株式会社スマートプラスを子会社として設立し、7月の取引機能のリリースに向けて推進中であります。
自分は元々、金融工学をやっていてFinatextの創業にかかわり、今に至ります。

Fintech企業3社のエンジニアによるパネルディスカッション

justInCaseの加藤智さん(以下、加藤さん)
FOLIOの椎野孝弘さん(以下、椎野さん)
そしてFinatextの石橋淳志さん(以下、石橋さん)

各社のシステム構築について（Finatextのみ）

司会：今日は技術的なCTOやチーフサーバーエンジニアなどに来てもらっているので、システム構成や使い方などいろいろ掘っていこうと思います。それでは石橋さんお願いします。

石橋さん：これはスマートプラスの証券ビジネスのものです。
アピールポイントとしては、マイクロサービスですべてのサービスがコンテナ化しています。
各ECSの役割としては、3つの役割があります。

クライアントに対するAPIサーバーとしての役割（アプリを複数展開していく予定があるため）
インターナルとしての役割
社内管理画面向けの役割

logはawslogsでCWLに集約、lambdaで整形し、必要なものはアラート通知してその後ElasticSearchに入れています。
最後にマイクロサービス化したときのひとつのテーマとして認証と認可をどうするかがあります。認証前・認証後でアクションが必要なケースはAPI Gatewayを介してLambdaで処理したり、CognitoのトリガーとしてLambda Functionをつけたりしています。認可は内政の認可サービスではgRPCを使っています。

モチベーションとしては認可サービスは今後増えていくサービスの殆どのものと疎通すると思います。
サービス間のインターフェイスをスキーマ言語のProtocolBuffersで維持できるのかなと考えています。

また、証券の場合、ほかのウェブサイトとは違うのはマーケットが開いている時間は営業日の9～15時で、ここで一気にスケールしたサーバーで処理したいのですが、そこでLambdaをスケジューリングして、市場が開く前にはサーバーを増やして、終わったら落としてという経費削減を行っているところです。

AWSとアーキテクチャを使っているポイント（Finatextのみ）

司会：ありがとうございます。前提条件としてシステム構成をお話しいただいたので、これから質問に移っていこうと思います。各社にAWSとアーキテクチャを使っているポイントとか困っている点をお話しいただこうと思います。それではFinatextの石橋さんはどのように活用されているでしょうか？

石橋さん：SSM を使ってPatchBaselineで起動しているサーバのパッチコンプライアンス、clairでdockerイメージの脆弱性診断、CloudTrailで操作ログ、GuardDutyで継続的なセキュリティ監視、MacieでCloudTrailログの分析、Configで設定変更の監視、その他CWE + SNS or Lambdaでのイベント検知・報告、構成管理はterraform で行っています。

変更監視だったりconsoleログインだったりと言ったところの対策は個別の事案を洗い出してそれぞれに地道に実装を組むなり運用を考えるなりする必要があり、網羅的にするのは結構めんどくさいですね。

でもfintechリファレンスアーキテクチャでFISCのコンプライアンス項目と対応してawsの言葉で対策実装方針が書かれてるので開発者としてはissueに落とし込んでくれている感じで対策しやすかったですね。社内でいうと、Fintechリファレンスアーキテクチャによってコンプライアンス部門やシステムに詳しくない人とのコミュニケーションが円滑になったかなと思います。

司会：ありがとうございます。SSMのパッチ管理やMecieでセキュリティオートメーションを行っているそうですが、何人で運用・構築をしているのですか？

石橋さん：エンジニアは全部で10人です。人数は少なくてもissueは細分化されているので対応できるかなと感じています。組んでしまえば自動化されるので。

システム構成でのエンジニアの悩み 苦労しているポイントと解決方法

司会：ありがとうございます。押し売りになっていないといいですが(笑)　3社さんともポジティブなポイントをもらえていますが、フィンテック企業ならではの悩み、システム構成でのエンジニアの悩み、周辺業者とのかかわりの悩み、リファレンスアーキテクチャ・AWSもっとこうだったらいいとか、またお互いこうしたらいいよとかを伺えたらと。苦労しているポイントと解決方法はいかがですか？

Finatextの石橋さんはどの辺で苦労であるとか乗り越えたポイントなどがあるでしょうか、あればお聞きしたいんですが。

石橋さん：3つ個人的にあって、一つはDXの専用線あたりに代表される外接部分とクラウドのベストプラクティスのステートレスでスケーラブルにするかの共存をどう構築していくか、次がマイクロサービス化しているときにサーバー間の設定項目の保守運用、3つめがセキュリティを担保しつつビジネスを加速していくことの両立です。

1つめはマイクロサービス化していることにうまくレバレッジをかけてステートフルな部分をできる限り小さなコンポーネントに閉じ込めてほかはクラウドのプラクティスに乗せていくという感じです。

司会：そこで言っている専用線を切り離してというのは、ほかの会社さんとの接続部分のことですか？

石橋さん：発注のプロトコルとかでネットワークの制約が多くて。

司会：なるほど。マイクロサービスで設定項目が増えているのはテクニカルな問題ということですか？

石橋さん：うちでトライしているのは開発・ステージング・本番などでawsのアカウントを分けており、rds clusterのエンドポイントなどはIDを同じにしてれば、そっちのaws apiで解決できるようになっています。SSMのParameter StoreやSecretsManagerなどもです。

社内SDKとしてgolangのパッケージを作っており、かつ他の言語でも使えるようにhttp+jsonでひけるコンテナも作成しており、マイクロサービスの設定が増えていくテクニカルな問題開発環境・・でデータベースのアカウントわけているランタイムで解決して行えるように、アプリケーション設定者の運用ミスをなくそうとしています。

セキュリティとビジネスの活用に関しての意見としては、ビジネスを加速させるにはビジネス管理者にアドイン権限を全員に作ればよくて、ただ一方でセキュリティを高めるためには何もしないとかデータ取得しない方がよくて、証券ビジネスをやるうえではお客さんのお金を預かっているので、セキュリティをあげつつお客さんの利益をどう上げていくかが大切になると思います。

そこで重きを置いているのは社内の管理画面でもユーザーと同じ構築をしていて認証認可のサービスの仕組みで構築していて、論理的には必要な部分だけを細分化できるようにしていて、最初は最小権限以下でもいいと思っていて、必要があれば社内の人間にも付与していきつつ、そこで運用コストがかかってきたらうまくAWSのサービスを使いつつ、運用を自動化して、自社のサービスで加速度を高めていくといったところです。

石橋からFolio椎名さんへの質問

マイクロサービス化したオンプレからAWSに乗せていく時にどうやって入れたのか。

司会：ありがとうございます。最小権限の原則の守り方いいですね。少ないところから始めて。その分大変なところもあると思いますが。ここでお互いに質問はありますか？

石橋さん：椎野さんに質問です。マイクロサービス化したオンプレからAWSに乗せていくということですが、うちでは内部的なAPIサービスがあって、そういうのをどうやって入れていくんですか？

椎野さん：そうですね。うちは9段階で半年近く移行しました。実際、移行しているときもコンプライアンスはこれでいいのかというところも平行に進めました。質問とずれるかもしれませんが、基本的にはコンプライアンスクリアになったところから移行しました。依存関係がかなり複雑なので、その依存関係を崩さないようにオンプレミスとクラウドをつなぐのをどうするかのプランニングに一番時間がかかった感じです。

司会：ほかにどうですか。加藤さんどうぞ。

加藤さんから、Finatext石橋さん・Folio椎名さんへの質問

マイクロサービスのトレーサビリティについて何かされていますか

加藤さん：2人に質問です。マイクロサービスをけっこうつかっていらっしゃいますが、弊社もマイクロサービスに拡張したいのです。ほかの業界もだと思うのですがやっていくとトレーサビリティが難しそうだなと思っていて、なにかあったときにユーザーのデータが分散してしまい、あとから大変そうだなと思うのですが、お二人はマイクロサービスのトレーサビリティについて何かされていますか？

石橋さん：個人的には同じ問題意識で、今後どうしていこうかなと思っています(笑)

椎野さん：

完璧にできてはいないものの、次はXrayを使っていきたいです。今は移行中でチップ金を使ってユーザーごとのフローをやっています。直近の場合エージェントが複数でめんどくさくて属人的で結局ログを見るみたいな(笑)最初からちゃんとXray入れていくことを意識して構築していけば防げるかなと思います。

最後に一言

司会：名残惜しいですが最後に簡単に30秒ずつ、今後の展望や考えていることをお願いします。

椎野さん：我々はフィンテックに導入しています。AWS上でみなさんが使いやすいプラットフォームを作りたいと思っています。

石橋さん：

うちは証券ビジネスプラットフォームを作っていて、これからさまざまなサービスを引いていく予定です。個人的なイメージとしてAWSさんはユーザーのフィードバックに向けて確実にほしいサービスを出してくれる印象があります。なので運用者としてうちの今後のビジネス拡大にも協力してやっていけると思っています。

司会：

ありがとうございます。ぜひ厳しいフィードバックをください。

加藤さん：

うちは7月に開業予定です。まだまだ全然ほかの2社さんよりまだ若い会社で、することも山積みですが、これからAWSさんをフル活用させていただいて、最少人数で最高パフォーマンスを出していく予定なのでよろしくお願いいたします。

司会：

以上でこのセッションを終了させていただきます。ありがとうございました。