@akitsukada)です。スタートアップとして不可避であるセキュリティ・コンプライアンスの高い要求をいかに合理的に対応してきたかなどをより深くお伺いします。DynamoDBに1TB/月の新規データ書き込み、少なくない量ですね。データ容量やキャパシティユニット費用など、コスト面で工夫などはされていますか?そうですね。ストレージ容量を節約しています。移すようにしています。走る可能性があります。トリガーされるように設定しておく必要がありますよね。起動されることになります。分の起動時間を合計するとけっこう大きくなってしまい、けっこうコストがかさむ...うーん、どうしようかな。機能についてはこちらの資料48ページをご覧ください。上げて過去分を保存するようにしました。処理したときのコストと比較して決定した、という流れですね。なく、スケールアウトのタイミングをスケジューリングしたりもしていますか?はい。Lambdaを使って一斉にスケールアウトさせています。9時前にも同様ですね。必要なくなったら落としたりしつつ、うまくコストダウンとパフォーマンスの要件を満たせるようにしています。今後は市場の動き方だったりユーザーの動向だったり、より有機的な要因を掴んでプレディクションを行い、より滑らかにスケーリングさせていきたいと考えています。そこにしっかりと取り組んでいこうとすると、将来的には機械学習を手がけるエンジニアを今よりもっと増やしていくことになるかと思います。提供している予測スケーリングではなくて、より業界事情を反映した独自の指標を持って需要を予測していくということですね。面白いですね!そうですね。政治的なイベントがあるときは市場の売買がより活発になったりするんですが、そうした外部環境もしっかり加味していければと思います。長いタームで学習し、バッファをうまく持たせながらも最低ラインのような部分をうまくプレディクションしていきたいですね。ついてももう少しお聞きします。的なシステムアーキテクチャ手法を割と初期から採っていますよね。なくしっかりサービスを分割して設計されていたり、といったところが特徴的なのかなと思っています。私にもかなり初期の段階からご相談いただき、あれこれディスカッションした記憶があります(その節はありがとうございました)。読者の方に、スマートプラスのシステムを作り始めるとき、どういう判断でアーキテクチャを決めていったのかをご紹介いただけませんか?まずサービスに必要な機能をモデル化していったとき、責務や利用したい技術が明確に異なる箇所が複数あったんですよね。接続されるシステムがあったり。証券会社に接続するところでは、オンラインで証券取引を行う際のスタンダードなプロトコルであるFIX(Financial-Information-eXchange)をしゃべるサーバが必要だったり。いわゆるバックオフィスのサービスとつなぎこむところ、データを取り込むところがあったり。あと、各種の権限制御については請求に関連する複雑な要件があったので、サービスとして一つにまとめていたりします。「ここを分けておくと作りやすそう」という単位で分割していった感じですね。扱うデータや求められるコアな機能と果たすべき業務範囲、パフォーマンスやセキュリティの要求レベル、その後の機能拡張の生じ方などが違ってくる単位で分けていきました。的な意味でのドメイン単位で分割したとも言える気がしますね。関係が深いところではありますが。言語をメインに採用したのは大きかったです。テンプレートが利用できるので、全体として導入しやすかった。EC2上で動かすよりも、ある程度ステートレスなアプリケーションとして作らざるを得なくなる点はいいですね。向上につながっていると思います。上では、先ほど紹介した構成図にある以外にも、長時間走らせる必要のあるプロセスを多くサービスとして動かしていますね。活用されていることがよくわかりました。フロントに関わるところでお使いだったと思います。どんな処理を行っていますか?そうですね。注文に対する約定情報の処理に使っています。受け取って処理しています。処理の順序に沿って図の上半分、左側から、注文の処理について説明します。エンキューするサービスがあります。プロトコルで証券会社に注文情報を送ります。使ってメタデータを管理しながら頑張ってアプリで実装していました。キューが東京リージョンでもローンチされたためすぐに使い始めました。便利ですね、FIFO。約定の処理を行うのは図の下半分、右側からです。情報を読みながらプッシュ通知などの必要なアクションを実行する、というものですね。処理を拡張していけば済むようになっています。次に、金融業界におけるスタートアップ、いわゆるFinTech企業としての事情をお伺いしたいと思います。ご登壇いただき、その先進的なセキュリティアプローチを詳しくお話いただきました。石橋さんと田島さんにより、特にセキュリティ面について深堀りされている必見資料です。)実際のところを聞きたいのですが、証券という規制業界の中で、セキュリティ面やコンプライアンスにおいて苦労を感じることはありませんか?組織体制の部分でガバナンスを敷くことが結構多いですね。あれば全員が一丸となってサービスを作っていけるのですが、スマートプラスの場合はまず証券会社として果たすべき責務がありますし、社内での情報共有という面を見ても、必要以上に部署間で情報を共有しないなどのルールが設定されています。なると、自分の情報は人には自然に伝わらないし、人からの情報も勝手に自分のところに入ってくるわけではなくなります。そこは会社として、情報の取り扱いに対して強い意識を持っていますね。いった統制によって様々な情報と開発メンバーが物理的に遠くなることで、実際のサービス開発にも影響が出てきます。システムに関する情報で、「どのような構成で作っているのか」「どういうセキュリティ要件を満たしているのか」といった内容を、いかに他の開発者に分かる形にして共有するか。あとは、「全てクラウド上に作っている」という部分自体が証券会社としては新しいことなので、関係者にどうやってそれを認識し、理解してもらえるのか。いった部分にも配慮してきました。スタートアップの皆さんとも話をさせていただいていると、長く金融業界で経験を積んできたベテランな方をガバナンス担当者として招聘する、あるいはそういった方が経営など事業の根幹に関わっているのがパターンなように思います。それはやはり、実際の現場経験、肌感覚を持っている人材が関わる必要があるからだと思うのですが。スマートプラスにはどのようなタレントがいるのでしょうか。スマートプラスはもともと、基本的に知見が豊富な証券業界出身の人が中心なんです。旧来のやり方を踏襲してきたというよりは、新しい技術やクラウドで対応方法を再発明しながらここまできた、と言えます。従来求められてきたセキュリティ要件や慣習は、まだ十分にクラウドが考慮されたものではなかったりするのですが、それに対して僕たちは「今の技術を使えばこの要件はこう整理、対応できるよね」と解釈し直して、合理的な対応方法を取ろうとします。いった要件は、抽象的、概念的に書かれることが多いので、解釈の余地が大きいんですよね。「自分たちで作っているものをどう解釈するのか」が大切です。曖昧な要件に対して、「こうすれば現代の最適解になるのではないか」と解釈するわけですね。よる組織統制などですね。監査の要件の中にはリソースの管理だったり、各種の棚卸しが必要なものがあったりします。履歴付きで管理・可視化できていると言えますよね。上で本番環境の状況が把握できます。組織とアカウントの管理に活用しています。作り、他のアカウントを配下に入れています。系の操作を制限するなどコントロールしています。ログは集約管理用のアカウントに集めて一括チェックしていたり、万が一各アカウントに侵入されても大切なログは守れるようにアカウントを分離したり、工夫しています。監視や権限制御を実装するとか。一覧や状況を確認することができます。定期処理を定義していたらこれはできないですよね。リファレンス・アーキテクチャーに基づいたレビューなどはとても役に立ちました。いった金融文脈の事情、コンプライアンス要件に直面してきたエンジニアは、スタートアップの中にはまだ少ないのではないかと思います。エンジニアのボリュームゾーンとしては、いわゆるWeb系出身のエンジニアの方が多かったり、とか。業界に身を置く石橋さんとしては、こういう詳細なコンプライアンス要件をぶっちゃけめんどくさいと感じる瞬間はありますか?いや、まぁ頑張ってますが(笑)、めんどくさいとは思わないです。実際、そういった要件をいかに最新技術でクリアしていくかといった面は楽しいですよ。証券業界の経験豊富な、頼りになる仲間も多いですし。これまでやってきた中で、何か読者の皆さんに共有できる失敗談や学びなどあれば教えてください。今にして思えば、開発初期の段階からもうちょっと設計と考慮をしておくべき箇所もあったなと思います。機能性を実現することが優先される開発の初期開発だとデータ分析をする要件自体がまだなかったりしますよね。今になって、たとえばマーケターから「こういうデータがほしい」と言われたときに、そのデータがなかなかすぐに出せなかったりすることもあり、結果ビジネスのスピードに影響を与えてしまったりもします。データの設計だったりログの収集方法だったり、可視化や分析の仕方だったり。使ったログ分析基盤を構築しています。今後についても教えてください。いったところにチャレンジしていく予定がありますか?開発面でも、ビジネス面でも結構です。サービス間のインタフェース、通信プロトコルをより柔軟にしていきたいです。メリットが出るように選べるようにしていこうと思っています。その先としては、分析基盤に乗っける可視化・分析用のアプリケーションを作ることもしたいですし、さらにデータがしっかり活用できる状況になってきたら、ユーザーさんにメインの取引ツールとして使うサービスをサジェストしていくようなこともやってみたいと考えています。冒頭の紹介で言ったように、ユーザーさんによって株への取り組み方や目的は様々なはずなんですよね。積立メインのサービスがあったり、よりテクニカルなサービスがあったり、ユーザー特性によって適したサービスがあっていいはず。最初試しにどれかを使ってみてもらって、その後さらにその人にあったツールをサジェストする、レコメンドする感じですね。ありがとうございます。ブログの主な読者はスタートアップにいるエンジニア、またはスタートアップに興味のあるエンジニアの方です。読者へのメッセージをお願いします。