WealthNavi Tech Talk vol.1_2023.11.14

WealthNavi Tech Talk vol.1 「ものづくり」する金融機関のエンジニアが 語るロボアドバイザー開発の舞台裏 - バックエンド開発特集 #WealthNaviTech CONFIDENTIAL 1

イベントの主旨・目的 ウェルスナビではエンジニア・デザイナーが主体となり、開発組織の文化づくりを推進してい ます。 技術広報活動の一環として、「技術を切り口に弊社についてもっと広く知っていただきたい」 「弊社の技術知見を共有したい」という思いから、本イベントを企画・開催しております。 一連の活動はエンジニアを中心とした有志メンバー（AMO*）が推進しており、開発組織内 のコミュニケーション活性施策推進、エンジニアブログ** などでの情報発信を行っておりま す。（#WealthNaviTech） *AMO:「開発組織の活性化」を目指して技術広報活動を推進しているチーム AMOは”Accelerate Manufacturing Organization”の頭文字をとったもの **エンジニアブログ:「ウェルスナビ開発者ブログ」に記事を寄稿しております。 https://tech.wealthnavi.com/ CONFIDENTIAL 2

• https://tech.wealthnavi.com/

WealthNavi / ウェルスナビについて （執行役員VPoE 和賀） CONFIDENTIAL 3

自己紹介 カラダノート LegalOn Technologies CONFIDENTIAL Talent X ROBOT PAYMENT 4 カオナビ HiManager Yahoo! JAPAN

WealthNavi / ウェルスナビ について ※画面はイメージです ※一般社団法人日本投資顧問業協会「契約資産状況（最新版）（ 2022年9月末 現在）『ラップ業務』『投資一任業』」を基にネット専業業者を比較 ウエルスアドバ イザー社調べ（ 2022年12月時点） CONFIDENTIAL 5

WNを支える開発組織について CONFIDENTIAL 6

【第一部】 バックエンド開発エンジニアによる 業務、技術知見紹介 CONFIDENTIAL 7

取引システムのコンテナ化と パフォーマンス改善 取引管理チーム 福田淳雄 CONFIDENTIAL 8

自己紹介 所属 取引管理チーム / ディレクター 出身・経歴 東京都出身 / 東京都在住 SIer → SIer → WN（金融証券業は初） Fukuda Atsuo 福田 淳雄 CONFIDENTIAL 技術スタック ・オブジェクト指向 ・モデリング ・DDD 9

取引システムのコンテナ化とパフォーマンス改善 1. コンテナ技術とは 2. 取引システムとは 3. コンテナ化までの道のり 4. 落とし穴 5. パフォーマンス改善 6. まとめ CONFIDENTIAL 10

1. コンテナ技術とは ● 爆発的な広がりをみせているコンテナ技術ですが、今一度おさらい ● コンテナ技術とは ○ 共有されたホストOS上でコンテナエンジンを使ってコンテナを起動することで独立したア プリケーションの実行環境を複数立ち上げるための技術 ● メリット ○ ポータビリティ ● 環境差異を気にすることなくどこでも実行できる ○ スケーラビリティ ● 複数のコンテナを簡単に追加できる ○ フォールトトレランス ● 可用性、耐障害性が向上する ● デメリット ○ セキュリティ ● それぞれのコンテナで適切な権限管理が必要 ○ ホストカーネルとの依存性 ● ホストカーネルの互換性次第で動かない場合もある CONFIDENTIAL 11

取引システムとは ● 本日お話する取引システムとは ○ 証券売買において受注、発注、約定の機能を実現するシステムのこと 入金 取引システム 入金 各お客様毎の証券口座 ①お客様毎の状況に応じて受注 処理を行う（50万件） ③取りまとめてNYSEに発注処理 を行う ②注文毎に銘柄・数量を決めて発 注処理を行う（70万件） ④取りまとめた注文の約定結果を 受け取り、各お客様毎に約定処 理を行う CONFIDENTIAL 12

コンテナ化までの道のり ● 目的 ○ EC2のOSアップグレード等運用保守をやめたい ○ パフォーマンス改善したい ○ デプロイを簡単にしたい ● やること ○ アプリケーションではDockerファイルを書くのみ！ ○ 環境変数の設定やGlassFishのInstallなど細かい対応はあったがファイルを書くのみ！ ECS Fargate EC2 instance contents Glass Fish / J2EE Glass Fish / J2EE 受注/発注 /約定 システム 受注/発注 /約定 システム コンテナ化 EC2 instance contents ECS Fargate Apache Tomcat / Spring boot Apache Tomcat / Spring boot 注文作成 システム 注文作成 システム CONFIDENTIAL 13

落とし穴 ● ● Dockerは偉大ですが、世の中はそんなに甘くない 通信部分に気をつけないといけない部分があった 市場に注文を出すためには専用 のgateway経由でアクセスする 必要がある もともとは同一EC2サーバー上 に存在していたのでlocalhostで アクセスしていた WealthNavi ECS Fargate Glass Fish / J2EE 受注/発注 /約定 システム gateway server CONFIDENTIAL 14

落とし穴 ● ● Dockerは偉大ですが、世の中はそんなに甘くない 通信部分に気をつけないといけない部分があった gateway serverにはIP制限があ り登録したIP以外からはアクセ ス出来ない コンテナは起動のたびにIPが変 わる WealthNavi ECS Fargate Glass Fish / J2EE 受注/発注 /約定 システム gateway server CONFIDENTIAL 15

落とし穴 ● Network Load Balancerを使って解決 NLBを使ってアクセス元のIPを 固定化 ECS Fargate Glass Fish / J2EE 受注/発注 /約定 システム gateway server CONFIDENTIAL 16

パフォーマンス改善 ● ● ● コンテナ化をして最も効果的だったのはスケールアウトによるパフォーマンス改善が容易になったこ と 現在はMaster node × 1,Worker node × 6 で処理を行っている 約50万件の注文受付処理が20分程度で完了する （コンテナ化だけが改善要因ではないが元々1.5h程度かかっていた） Master Worker1 CONFIDENTIAL Worker2 Worker3 Worker4 Worker5 17 Worker6

まとめ ● コンテナ化自体は難しいことは基本的に無く、問題なく進めていける ● サードパーティ製のアプリなど利用している場合は注意が必要 ○ コンテナ化できない ○ 通信に制約がある ● 最もメリットを感じているのはスケールアウトが容易になったこと CONFIDENTIAL 18

金融未経験からFintech ベンチャーにJoinした サービス機能開発チーム マネージャー 大友 CONFIDENTIAL 19

自己紹介 出身 宮城県仙台市 経歴 - - 広告代理店にてガラケー公式サイト 開発運営 ココネ株式会社 - アバター系ソシャゲ開発運営 - 10年ほど在籍 - 子会社CTO ウェルスナビ - 2023年6月 〜 大友 秀輔 サービス機能開発チーム マネージャー CONFIDENTIAL 20

はじめに CONFIDENTIAL 21

はじめに ソシャゲ界隈でのエンジニアだった私が、どう興味を持ってFintechベンチャーに転職をした のか。そして入ってからどのようなギャップがあったのか、入社から半年近くが経ち、どのよ うな働き方だったのかをご紹介します。 今とは違う会社に興味を持たれるきっかけになればと思います。 CONFIDENTIAL 22

ウェルスナビ入社以前 CONFIDENTIAL 23

ウェルスナビ入社以前 広告代理店 (遠い昔) - - ココネ株式会社 (10年在籍) ガラケー公式サイト開発運営 - デコメ、クイズ、図鑑、etc - 後にスマホ対応 技術スタック - PHP （5.4とかそんな時代) - ZendFramework - MySQL - オンプレ - など - - アバターサービス - ポケコロ - ココネッツ 音声ライブ配信サービス - 私を布教して Play 2 Earnサービス - ClawKiss 技術スタック - Kotlin, Java - SpringBoot, Spring Framework - MariaDB, MongoDB, Redis - AWS, オンプレ - など 所謂ソシャゲを開発してきた CONFIDENTIAL 24

ウェルスナビ入社以前 いろいろあって転職を考える CONFIDENTIAL 25

ウェルスナビ入社以前 脳内のご様子 CONFIDENTIAL 26

ウェルスナビ入社以前 自分の課題とその会社が解決しようとし ている社会的課題が合致しているサー ビスに携わるのっていいのかもしれな い。 なんとなく CONFIDENTIAL 27

ウェルスナビ入社以前 興味・関心・課題 - 医療 - 家族が持病を抱えている 医療費かさむ 自分も病院にいく 病院間ってなんで情報共有してないの? (闇) - 物流 - amazonでいろいろ買う 再配達大変そう (いつもごめんなさい) last 1 mile 聞いたことある - お金 - CONFIDENTIAL ない 老後2000万問題 自分が死んだら家族は? どうすればいいかわからない 28

ウェルスナビ入社以前 幸いなことにいろいろお声がけいただき、いろいろ カジュアル面談して、いろいろ面接して、 ウェルスナビに決めた。 一番の決め手 CONFIDENTIAL 29

ウェルスナビ入社以前 面接が楽しかった いろいろあるがそんなもん CONFIDENTIAL 30

入社 CONFIDENTIAL 31

ウェルスナビ入社 何もわからん CONFIDENTIAL 32

ウェルスナビ入社 感じたギャップ - 転職での環境の変化 (10年どっぷり浸かったものからの脱却) - 社内関係性のリセット - 阿吽の呼吸 - 文化の違い - 社内ルール・社内用語 - 幸いなことに社内業務で使うようなツールは経験済。(Slackとか) - やっていいことだめなこと - 会議室の場所とか地味に細かいところが悩んだ - 金融の知識 - 社内用語なのか金融用語なのか分かる部分と分からない部分 - 大体わからない CONFIDENTIAL 33

ウェルスナビ入社 わかること - 開発のこと - 人との関わり合い CONFIDENTIAL 34

ウェルスナビ入社 同じグループあるいは業務に関わりありそうなチーム責任者の方との 1on1を 入れて、関係性を構築を目指す。10数名。 CONFIDENTIAL 35

ウェルスナビ入社 急に全然知らない人に凸とかよくやったと思う・・・ CONFIDENTIAL 36

ウェルスナビ入社以前 お仕事 CONFIDENTIAL 37

ウェルスナビ入社 だいたいわからん CONFIDENTIAL 38

ウェルスナビ入社 チーム開発ならわかる やるしかない CONFIDENTIAL 39

ウェルスナビ入社 やったこと(継続中) - チームを超えてタスク管理 - 週1で進捗確認会。定例化。 - WBS的なものの用意。Notionでやった。 - 全員にタスク割り振り 期日もとりあえず引く - ステークホルダーとのMTG - 開発がGOになった時点で各担当リーダーのMTGも発足 - 進捗共有した - あとは進めるように根回し - 今のとこオンスケ<- 大事 - わからんけどわからんなりに情報集めて進める CONFIDENTIAL 40

これから CONFIDENTIAL 41

これから - - 慣れる まだなめらかな業務進行ができないと感じる - 業務フローの問題点調査 - 管掌範囲の業務の把握と周知 - 他チームとの連携 チームメンバーの拡充 - 倍にはしたい(ピザ2枚) 金融知識 CONFIDENTIAL 42

金融未経験からFintech ベンチャーにJoinした 今の感想 CONFIDENTIAL 43

金融未経験からFintechベンチャーにJoinした今の感想 - わからないものはわからん - 自分の強みを理解しつつ - 空気を読まないことも必要 - 新しいことはそれなりに大変 - 新しいことはそれなりにたのしい CONFIDENTIAL 44

持続可能なデータアーキテクチャを 実現したリアーキテクティング ソフトウェアエンジニアリング 浦野 勝由 45

自己紹介 浦野 勝由（Urano Katsuyoshi） ウェルスナビ株式会社 ソフトウェアエンジニアリングチーム / ディレクター ウェルスナビでは ● 2016年にフリーランスとしてウェルスナビに参画 ● 2018年から正社員としてAPI開発および基盤構築を主導 ひとこと ● 身長が183～4cm あります 46

アジェンダ 1. 2. 3. リアーキテクティング データ移行 アプリケーション移行 47

ざっくりデータフロー 証券残高等ポートフォリオを構成するデータを持つテーブルが肥大化し、バックエンドの様々な処理で遅 延が発生している これまでの対応 ● バッチ処理はサーバーのスケールアウト、処理の多重化などで性能改善を推進 WealthNavi （顧客口座） 入出金 取引 主DB 残高 管理 今回のスコープ 継続的なバッチ性能改善 48 勘定系

リアーキテクティング 49

Overview - リアーキテクティング ● ● 過去データ（履歴）はDynamoDBへ移行 最新断面（基準日～営業日）のみRDSから生成 Before：全期間スキャン RDS After ：期間指定スキャン＋履歴参照（Dynamo） DynamoDB 50

DynamoDBテーブル設計 DynamoDBテーブル設計 パーティションキー ユーザーID 文字列 ソートキー 基準日 文字列（YYYY-MM-DD） 値（Attribute） ポートフォリオ JSON 通常、DynamoDBのテーブル設計は難しい ● ほとんどの場合一つまたは少数のテーブルで対応することがベストプラクティス(*1) ユースケースが単純だったため、ベストプラクティスに則ることができた (*1) https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-table-design.html 51

• https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-table-design.html

DynamoDBデータ取得アーキテクチャ NewPortfolioService テーブル（Portfolio） 複数スレッドで重複しない 期間のデータを取得するこ とでレイテンシーを極小化 （※） ※スロットリング制約あり（後述） Speed ユーザーIDによるパーティショニング ユーザー増加がスループットに影 響しない設計 ユーザーN ユーザー1 Scalability 基準日で分割 52

Testcontainer＋LocalStack TestcontainerのLocalStackModuleを使えば、モックを用意しなくてもリアルな依存関係（エミュレートさ れたAWS環境≒本番環境に近い条件）を含むテストを簡単に実装できる build.gradleに以下を追加 testImplementation 'org.testcontainers:localstack:1.19.1' (*4) Testcontainer LocalStack (*4) 2023年11月時点の最新バージョン 53

AWS STS＋AssumeRole 必要なアクセス権限が付与されているロールの一時的な認証情報をSTSから取得してリアルなAWS（開 発）環境へアクセスする いずれかの認証プロバイダーを使う ● com.amazonaws.auth.profile.internal.securitytoken.STSProfileCredentialsServiceProvider ● software.amazon.awssdk.services.sts.auth.StsAssumeRoleCredentialsProvider 一時的な認証情報 IAM Developer ロール DynamoDB 開発端末 54

Scan vs Query ScanではなくQueryを使用できるように設計 テーブル テーブル Query Scan Scan ● 常にテーブルまたはセカンダリインデックス 全体をスキャン Query ● パーティションキー条件必須 ● 条件に合致する範囲のみスキャン 55

データベース負荷軽減と持続可能性 After ：期間指定スキャン＋履歴参照（Dynamo） Before：全期間スキャン DBのスキャン範囲を限定し、返却データ量を少なくすることによりSending data状態の負荷を大幅に軽減 データセットのライフサイクルを設計および開発段階から考慮することが重要 ※パーティショニングやシャーディングによって実現できる場合も アーカイブ※ 56

データ移行 57

バッチ処理アーキテクチャ StepFunction Batch Publisher (1) Subscriber (N) s3://~ SQS DynamoDB Fanout S3 RDS (Reader Endpoint) 58

Spring Batch ● ● ● Jibでコンテナ化 起動引数で使用するリソースやジョブ（ApplicationRunner実装クラス名）を指定 実行が終了したらコンテナを終了 ジョブ定義 環境変数 Batch 名前 (Spring Batch) コンテナ 値 起動引数 スレッド数 入出力リソース 59

Provisioned vs Ondemand プロビジョニングでデータ移行を実施し、移行完了後にオンデマンドへ移行（予定） CU（キャパシティユニット） スロットリング 上限CU デフォCU 費用発生領域 ユーザーがCUを管理 DynamoDBがCUを管理 Provisioned ● スループット要件を満たすCUを事前確保 Ondemand ● デフォルトのCU設定あり ● ピークトラフィックの最大 2 倍まで瞬時に対 応 読み取り（RCU）、書き込み（WCU）それぞれで上限緩和申請可能 デフォルトのクォータは 40,000CU (*5) (*5) https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/ServiceQuotas.html#gt-limits-throughput 60

• https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/ServiceQuotas.html#gt-limits-throughput

ホットキースロットリング 単一のパーティションに対して、上限を超えてアクセスを行った場合スロットリングが発生 ホットキースロットリング 書き込み上限（秒） 1,000 WCU 読み込み上限（秒） 3,000 RCU パーティション パーティション制限に関しては上限緩和申請できません 61

DynamoDBの制約・はまりポイント ● キャパシティモードの選択 ○ プロビジョニング、オンデマンド ○ モードの切り替えは1日1回まで ● スロットリングの存在 ○ テーブル、パーティションキー ● バッチ処理 ○ 一度の書き込みリクエストで送信できるアイテム数は25（BatchWriteItem） ● コスト ○ 消費キャパシティーユニットとデータストレージ量で課金 ○ データサイズが大きいと（とても）費用がかさむ 62

Trial and error history ● (RDS) Too many connections ● Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key ● The level of configured provisioned throughput for the table was exceeded. Consider increasing your provisioning level with the UpdateTable API ● Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key Capacity Mode max connections Turnig RDS Turnig CU vCPU・Memory Array size Batch DynamoDB Java threads 63

ベストプラクティス ● キャパシティプランニングと事前ウォーミング ○ 消費CU／秒 ■ 1スレッド辺りのスループットの正確な計算 ● 再試行 ○ 一時的なスロットリングに対して有効 ○ レイテンシーが許容できて、かつエラーレートが増加し続けなければ正常の動作 ○ SDKで対応可能 ● テーブル設計は慎重に ● データサイズは極力小さく 64

事前ウォーミング 最大CUが見積可能であれば、プロビジョンドモードで負荷試験をすることでオンデマンドの最大許容 CU を設定することが可能 ③ キャパシティモード切替 プロビジョンド オンデマンド 過去最大 Consumed CUの2倍が上限 消 費 キ ャ パ シ テ ィ 消 費 キ ャ パ シ テ ィ ① 必要な最大CUの見積 ピーク時でもスロットリングが 発生しない ② 負荷試験 時間 時間 65

アプリケーション移行 66

ストラングラーパターンによるアプリケーション移行 許可されたネットワークからのみV2へのアクセスを許可 機能の一般開放前に十分な比較検証を実施 WealthNavi ユー ザー RDS 比較検証 V1 Office Internet ALB DynamoDB V2 67

フューチャートグルによるプロダクト毎の移行 DynamoDB利用フラグは複数のスイッチにより制御 ● グローバル設定（DB） ● アプリケーション設定（プロパティファイル） ● 環境変数（$ENV） DynamoDB利用フラグ OFF プロダクトA RDS（Aurora） DynamoDB利用フラグ ON プロダクトB RDS（Aurora） DynamoDB 68

Next Future ホットキー制約回避等のため、将来的にはDynamoDB以外のストレージに履歴データを移行 持続可能なデータアーキテ クチャを維持 ネイティブアプリ RDS 最新データ のみ取得 端末にキャッシュ Webアプリ DynamoDB エクスポート S3 S3にキャッシュ 69

SWEチームの紹介 ミッション・ロール ● 持続可能な開発を実行できる環境・基盤を構築 ● 技術的負債を管理し適切に対応するための開発戦略、戦術を提供 ● 適切なソフトウェアアーキテクチャを実現するための実行部隊 Latency Container Integration Framework Performance SQL Resillience Pub/Sub Log Architecture Cloud Java Security Event-Driven 70

ー 宣伝 ー 2024年2月に次回イベントの実施を企画中です。 詳細が決まり次第、connpass上で告知させていただき ます。 CONFIDENTIAL 71