全自動資産運用サービス 「ealthavi」 >ímazon >íurora移行 & コン … ·...
TRANSCRIPT
全自動資産運用サービス「 ealth avi」
mazon urora移行& コンテナ化事例
ウェルスナビ株式会社
取締役 & 井上正樹
サービス基盤アーキテクト 浦野勝由1
1 会社紹介
開発チーム
ウェルスナビ システム3
2
genda
2
uroraデータベース移行4
クラウドネイティブな基盤へ5
1 会社紹介
開発チーム
ウェルスナビ システム3
2
genda
3
uroraデータベース移行4
クラウドネイティブな基盤へ5
2016 社会問題を解決する
自己紹介
ウェルスナビ株式会社
取締役 &
井上 正樹
4
システムエンジニア
グリー インフラ責任者 & 事業責任者
ウェルスナビ ＆
2006 巨大インフラ構築
ゲーム事業責任者
1994 業務システム開発
5
WealthNavi 、
テクノロジー 力で、
世界水準 資産運用を
全自動化
働く世代に豊かさを
資産運用 全プロセスを自動化
富裕層が行っている資産運用を自動化してすべて 人に提供
6
運用 手間をゼロに
富裕層が利用する金融アルゴリズム
心理的なミスジャッジを防ぐ
© WealthNavi Inc. 2017-2019 All Rights Reserved.
※※
※一般社団法人日本投資顧問業協会「契約資産状況( 新版)（平成30年3月末現在）」よりモーニングスター社調べ(平成30年8月時点)※※時価評価額(2019年4月1日時点) 7
「も づくり」する金融機関
ision
9
会社紹介
設立 2015年4月28日
代表取締役 柴山和久
事業内容 金融商品取引業
社員数 79名エンジニアが従業員 約半数
代表取締役 柴山和久
ealth avi 初期プロトタイプ 柴山自ら開発
日英 財務省で計9年間/予算/税制/金融/国際交渉に参画
そ 後、マッキンゼー（東京・ Y）で 、ウォール街に本拠を置く機関投資家向けに、
10兆円規模 リスク管理・資産運用をサポート
働く世代が豊かさを実感できる社会をつくりたいという想いから、2015年4月にウェル
スナビを創業
東京大学法学部、ハーバード・ロースクール、 卒業。ニューヨーク州弁護士
orbes 「起業家ランキング2019」で op 20
10
世界 フィンテックをリードする” intech250”に選出
資産運用をリードする16社に
※ nsights uture of intech 2017（https://www.cbinsights.com/research/future-of-fintech-2017/）11
1 会社紹介
開発チーム
ウェルスナビ システム3
2
genda
12
uroraデータベース移行4
クラウドネイティブな基盤へ5
異業種 融合チーム
• シンプレクス• 日立ソリューションズ• 野村総合研究所• ワークスアプリケーションズ
など
金融・ erインターネットカンパニー
• グリー• Yahoo apan
• ixi• yber gent
など
証券会社 & 資産運用会社
• 野村證券• ホールディングス• ゴールドマン・サックス証券• 証券• 三菱 モルガン・スタンレー証券など
13
ユーザ
基盤系
エンジニアチームも異業種
顧客体験 ビジネス
テスト
インフラ
アプリチーム
分析基盤
金融システムチーム
顧客体験を 大化 証券業務
デザイナー / クライアント / サーバーサイドが一体となって作る & 相互にチェック
ユーザービリティ 信頼性
14
アプリ基盤可用性
アプリ基盤
使っている技術スタック
顧客体験 ビジネス
テスト
インフラ
アプリチーム
分析基盤
金融システムチーム # Swift # Kotlin # Java
# Sketch # Invision
# Trello # Java # SpringBoot
# Sendgrid
# Docker
# Bitrise
# Golang# PagerDuty
# BigQuery
# Firebase
# Redash # Tableau
# Embulk # Digdag
# Jenkins# Jira # Datadog
# Kotlin
# Java # SpringBoot
# Slack
# Android Jetpack
# Swagger
# Aurora
# Rx # Zendesk # 証券取引システム
15
ユーザ
基盤# Scala
# Golang
# Espresso/XCUITest
# ECS/Fargate
# Terraform
応用研究も進めている
資産運用アドバイスを で提供
16
1 会社紹介
開発チーム
ウェルスナビ システム3
2
genda
17
uroraデータベース移行4
クラウドネイティブな基盤へ5
日本初！ に証券取引システム構築
※ AWS 導入事例：ウェルスナビ株式会社 https://aws.amazon.com/jp/solutions/case-studies/wealthnavi/
18
証券会社 銀行 家計簿ニューヨーク証
券取引所勘定系
CloudFront ELB EC2 WorkSpacesS3
アルゴリズムによる税金 適化機能
リバランス機能付き自動積立 − 全国300以上 金融機関から可能
銀行と 連携で、オンライン完結 − 本人確認情報を で連携し書留が不要
in ech領域で新機能をリリース
特許取得
日本初
即時口座振替 による即時入金機能
特許取得
日本初
日本初
日本初
※ リバランス機能付き：追加投資を行う際に、お客様 ポートフォリオと 適ポートフォリオと ずれを自動的に測定し、そ ずれを優先的に埋めるように、ETF（上場投資信託）購入を自動的に行います。
※ 「即時口座振替API」 、資金決済が可能な更新系API。「マメタス即時振替」における提供が住信SBIネット銀行初 接続事例
19
なぜ を選んだか
20
初期費用
運用費用
抑制
資金が潤沢で ない
スタートアップが
利用しやすい料金体系
コモディティ化
した技術 利用
属人化されたインフラに
ならないように
機能をできるだけ利用
インフラ
エンジニア 採
用
に準拠することで
エンジニアが採用しやすい
インフラが大事にしている点
21
金融機関として 前
提を理解
金融情報システムセンター（ ）/ 日本証券
業協会 / 金融庁などが公表しているガイドライ
ンや法令を理解した上でシステムを開発・運用
新しい技術
積極的導入
資産運用サービス 、長期提供が重要
・システム陳腐化リスク
・メンテナンス不能リスク
に対応するため、新しい技術 導入も前向きに取り組む
22
事業とインフラ 成長
創業期 成長期 拡大期
事業 フェーズ
インフラ 課題
ビジネス設計
サービス立ち上げ
人材不足・時間不足
属人的な技術選定
開発言語 混在
とにかく事業を
早く立ち上げたい！
ユーザ増加
安定性に課題
運用 非効率
システム 安定稼働
サービス急拡大
モノリシックなアプリ
事業多面化へ 対応 経営 期待値
インフラ 対応低限 対応を行い
事業を前にすすめる
開発言語 統一
リプレースマイクロサービス
コンテナ
ウェルスナビ 、ど ようにして
成長期を乗り越え
拡大期に挑んでいる か？
23
アジェンダ
1 会社紹介
開発チーム
ウェルスナビ システム3
2
uroraデータベース移行4
クラウドネイティブな基盤へ5
24
じめに
データ移行
アプリケーション移行
uroraデータベース移行
25
改善事例
自己紹介
浦野勝由
● ウェルスナビ株式会社
○ サービス基盤アーキテクト/プログラマ
サーバエンジニアとして （2016/11)
○ 基盤構築（アプリ、銀行、家計簿等）
○ そ ほか機能開発（積立、2段階認証等）
● 好きな サービス
○ 3
26
● 複雑な構成 サーバ(on 2)運用に限界
○ OS、DB、DFSと、クラスタやレプリケーションが関係し合っておりトラブル対応 難易度が高い
● データ量増加に伴い運用基盤 ボトルネックが顕在化
○ 複製処理 大幅な遅延、障害
データベース運用 課題
サーバ（ indows）
ailover luster
eplication
eplication
ほぼ全て システム
顧客
顧客管理システム利用者27
400GB3億超レコード
800GB80万ファイル
ストレージ管理
● 日次 速報 算出
● 本番データ（個人情報マスク済み）で 性能検証
● 障害ほか調査時 断面復元
複製処理 遅延
loud
本番 開発
本番
マスキング処理用
マスキング済み
開発者・分析者など
3他、 ツール
28
分析システムなど
マスキング処理と
● 個人情報を含むデータを本番 外へ持ち出せない
● 個人情報閲覧 限られた人間 みに許可されている
○ 、オペレータ
● マスク対象 おもな項目
○ 住所、氏名、性別、生年月日、メアド、電話番号
○ 口座名義人、口座番号
○ ユーザー識別子
○ 認証情報（ キーなど）
○ そ 他もろもろ
東京都渋谷区渋谷２ー１７－５ MASK ＊＊＊＊＊＊＊＊
29
移行先プラットフォーム選定
● 要件
○ 運用保守作業 課題を解決すること
○ 現行（ y でない商用 ）と同等以上 可用性
● 決定したプラットフォーム
○ urora for y （5.7互換）
● urora 魅力
○ クラスタ／サーバ／ストレージ管理が不要
○ 複製が数クリックで完了
○ ストレージ自動拡張
○ ゼロダウンタイムパッチ／フェイルオーバー速度
○ 高パフォーマンス30
インフラ
アプリ
スキーマ移行検証
データ移行検証
書換
アプリケーション修正
システムテスト
運用設計＆業務改善
● 移行要件
○ ダウンタイム 許容するが、可能な限り短く／切り戻し可能であること
● アサイン
○ アプリ4名、インフラ2名（いずれも専任で ない開発保守と兼務）
移行元 で 新規サービス開発や保守作業 並行 リリース凍結
安全に移行できることを 優先
データベース移行（切替）
プロジェクト計画
31
リハーサル実施
じめに
データ移行
アプリケーション移行
uroraデータベース移行
32
改善事例
と を組み合わせた移行手順
1. でテーブル定義と制約、インデックスを移行
2. 移行元 から uroraヘレプリケーション
a. 切替2週間前から継続的に実施（ ull oadと ）
3. uroraへ切替
4. 切り戻しに備え、逆方向レプリケーションを実施
切り戻し用
移行元 移行先 urora移行用レプリケーション設定
切り戻し用レプリケーション設定
4. 逆方向レプリケーションを開始
※ 移行元、移行先、DMSすべて 同一スペック インスタンス（ r4.4xlarge）33
● chema onversion ool
○ スキーマ変換
■ 表、インデックス、制約 変換を実施
■ 名称が64バイト超える場合エラーになる（ y 制限）ため、移行元 へ
64バイト以下になるようにリネームパッチを適用
○ アプリケーション変換
■ 評価レポートを作成したが、適合せず手動変換することにした
スキーマ移行検証
34
● ata igration ervice
○ チューニングしつつ繰り返し検証
■ 移行元 へ 影響を 小限に抑えつつ、データ転送速度も追求
データ移行検証
35
インスタンスタイプ 移行元 と同じ
初回 ull oad時間 1日と10時間37分
テーブル数/レコード数 344tables/約300,000,000records
並列度 8
コミット粒度 10,000
○ マルチバイト文字（外字、絵文字）や日本語 対応
■ 4バイト文字が を使って移行すると文字化け・欠損
● utf8mb4に が非対応だった（現在 対応済）
■ サロゲートペア検出クエリで4バイト文字混入カラムを事前調査
■ 型 日本語カラム を使うと文字化けした
● 移行元 対象カラムを 型に変更パッチ
○ 大きな文字列 対応
■ デフォルト 大長が32 （2バイト文字で16,384文字が 大）で 大長を超え
たデータ 欠損する
■ 32 より大きいデータが入っている場合 ull 設定(64 )で
まりどころ
36
良かった点
● 不要なテーブル、ビュー 整理
○ 評価レポートなどを通じて使用していないテーブルやインデック
ス 整理をすることができた
● テーブルサイズ スリム化
○ チューニングを行う過程で無駄に大きいフィールドサイズを見
直し、現状に即したサイズへリサイズできた
■ ( 大) など
移行負荷低減 名目で断捨離できた
37
じめに
データ移行
アプリケーション移行
uroraデータベース移行
38
改善事例
○ 全システム横断で修正／テスト
○ 現行同等 パフォーマンス維持
○ 新旧データ更新内容が一致
○ 48時間（1営業日サイクル）ジョブスケジューラ 網羅テスト
○ 移行作業期間中 リリース物（商用 版） merge＆ urora版へ変換
して再度テスト
だたひとつ、 uroraで動くこと・・・
全部やる ？
アプリケーションへ 要求
39
当時 lackで やりとり（抜粋）
● indow関数がない件
● 句がない件
y
ysql
mysql
my
40
ostgre 使う説ないですか？つらみがすごすぎ58 replies を記録
当時 lackで やりとり（抜粋）
● 照合順序 一致しない
● アプリケーション をあきらめ
41
1orz
まさか orz
自分で直せだってorz
1orz
orz
orz
orz
orz
チャネルがorz で埋めつくされた
● 実質4か月・・・ y ( urora)と向き合った・・・
さまざまな困難を乗り越えて・・・
(※) 残念ながら、時間 関係で反省点やノウハウ 本日お話できません。
アプリケーション移行
42
主要なチューニング
対象 項目
パラメーター スレッド関連メモリをデフォルトより大きめに調整
table_open_cacheをデフォルトより大きめに調整
バッファープール 予めウォームアップしてキャッシュしておく
● urora
● アプリケーション
対象 項目
性能問題が顕在化したため、一部 テーブルへ修正
サブクエリ 性能問題が顕在化したため、 を使うなどして修正
インデックス 追加した
43
じめに
データ移行
アプリケーション移行
uroraデータベース移行
44
改善事例
● データサイズと共に処理時間が増加
● 時間短縮 ためスケールアップしコストが増加
● 各サーバにスクリプトやスケジュール設定が散乱○ 処理失敗時 リカバリや変更が困難
loud
本番 開発NW
複製処理 改善（商用 ）
ダンプ
リードタイム
720分/回遅延増加ペース
60分/月
リストア本番
マスキング処理用
ダンプ
開発 開発者など
45
改善を積み重 スクリプトが複雑に（メンテ不能）
ネットワーク帯域限界
● 全て 処理をサーバレスに移行（ o実装）
○ マスキング処理（ ） 実行を並列化
● 処理 安定化と高速化（8倍）を実現
複製処理 改善（ urora）
本番
tep unction
①複製指示
atch
②マスキング処理指示
Step Function
loud atchvent ule rigger
本番
マスキング処理用
複製
③ atch完了通知
開発
開発
複製
④複製指示
リードタイム
90分/回遅延増加ペース
3分/月
46
スロークエリ 活用（商用 ）
● スロークエリ 活用状況
○ インフラ担当がトラブル時など 調査時に確認する程度
● 開発者へ フィードバック方法に課題
○ クエリに 顧客 情報が含まれているため、マスキング処理なしに開
発者に公開することができない
顧客情報が含まれるクエリ例）
SELECT * FROM CustomerAttributes WHERE Email = ‘[email protected]’;（公開できない情報が含まれている）
47
クエリ抽出やマスク作業 手動で実施していた。。
スロークエリ 活用（ urora）
● ngest ode機能でスロークエリログをマスキング処理
○ マスクキング処理でクエリがパターン化され分析が容易に
● lerting機能でマスク済みスロークエリを通知
○ lastic earch ervice組込み イベント監視とアラート機能
lastic earch ervice組込み 機能を活用することで加工と可視化と通知をノンコーディングで実現
low uery og
ngest ode （加工）
urora loud atchogs
lastic earch ervice
lack
pen istro lerting
（通知）
48
まとめ
● 運用負荷 改善
○ 複製処理 高速化、コスト削減
○ 複雑なクラスタ管理から解放されトラブル対応が容易に
● 運用改善 サイクルが回り始めた
○ 経由で オペレーションで運用改善が捗る
○ スロークエリなど 可視化で関係者全員に改善意識が芽生えた
本来やりたかった業務に時間を割けるようになった
49
アジェンダ
1 会社紹介
開発チーム
ウェルスナビ システム3
2
uroraデータベース移行4
クラウドネイティブな基盤へ5
50
現状 サービス基盤
● スピード重視で行った機能追加がモノリシックアプリケーションを
急成長させて、開発スピードが落ちている
○ ビルド時間遅延
○ コミュニケーションコスト増
○ 共通機能 アップデート 全て プロダクトリリースを伴う
事業 成長
開発
スピ
ード
事業 成長
開発
コス
ト
51
52
事業とインフラ 成長（再掲）
創業期 成長期 拡大期
事業 フェーズ
インフラ 課題
ビジネス設計
サービス立ち上げ
人材不足・時間不足
属人的な技術選定
開発言語 混在
とにかく事業を
早く立ち上げたい！
ユーザ増加
安定性に課題
運用 非効率
システム 安定稼働
サービス急拡大
モノリシックなアプリ
事業多面化へ 対応 経営 期待値
インフラ 対応低限 対応を行い
事業を前にすすめる
開発言語 統一
リプレースマイクロサービス
コンテナ
開発にスピードを取り戻す
（基盤も体制もスケールアウト）
直近 ミッション
● クラウドネイティブな基盤技術 採用
○ 2から ockerへ／ 非依存 機能開発
○ 、 mazon orretto ( pen 互換) 採用
○ リリースエンジニアリング 改善
■ スクリプト主体 エンジニアリングから ode ipelineなどへ移行
● モノリシックアプリケーション 分割
○ 小規模で頻度 高い改善（リリース） 実現
○ コードベース 分割／依存関係 整理
○ 自律的な開発運用体制へ（スケールアウト）
54
● ファイル共有ストレージを istributed ile ystemから mazon 3
へ移行○ ファイル共有ストレージを必要とするアプリケーションランタイム 依存
を解消
○ コンテナ環境（ディスクレス）へ 適応（ 選択しなかった）
loud
を 3へ移行
\\dfs.wealthnavi…\hoge\.. mazon 3
依存プロトコル
https:// or s3://
依存解消
依存
55
#ライブラリを avaへ移行
● 暗号化ライブラリを #実装から 実装へ移行
○ アプリケーションランタイム 依存を解消
○ コンテナ環境（ mazon inux2）へ 適応
loud 依存解消
暗号化／復号時に #ランライムが必要だった
mazon orrettoさえあれ よい
mazon orretto
依存
56
loud
次世代基盤アーキテクチャ
evelopers
itbucket ipeline（自動化）● mageを へ ● タスク定義更新
urora
loud atch ogs
3
archivepage/alert
pplication logs stream
● リリースチケット承認● 手順書（自動生成）● デプロイ● アラート対応
loud atch etrics
loud ront ode ipeline
57
● ウェルスナビ 事業成長とともにモノリスなバッチアプリケーショ
ンが巨大化し典型的な泥団子に
● 取扱データ量 日々増加
● 他社連携（ , ...）
● 性能維持 ため、 ス
ケールアップで対応
○ 非効率
○ 個別対応したい
巨大なモノリス
出金自動積立
外部連携 勘定系連携
家計簿連携
手数料計算
入金
58
● 巨大化したバッチアプリケーションから独立性 高いジョブを切り
出してコンテナ化（次世代基盤へ移行）
○ 事業的優先度が高いサービス（ジョブ）から順次切替
loud
次世代基盤
コンテナ移行
巨大化したバッチアプリケーション
( argate/ 2)
urora
59
質問 説明
タスク（コンテナ）に割り当てたいv が4以上か？
● argate 1タスクあたりv が4、 30 までしか割り当てられない
● 上限緩和される可能性あり（リクエスト多数）
データをホスト ディスクに永続化したいか？を使いたいか？
● argate タスク 停止と共にデータが消える● argate をマウントできない
ログを loud atch以外で管理したいか？ ● ogging driver loud atch/ plunk み対応● fluentdを使いたい であれ 2を使うべき
コンテナ 高速起動を要求するか？ ● argate イメージキャッシュが効かないため、 2よりも起動が遅くなる傾向
低コストを要求するか？（運用コスト含まず）
● argate 2に比べると1.25倍前後高い● argate 起動タスク単位 課金 ため、常時起動
する必要がないバッチジョブなど コストが逆転する可能性あり
2 vs argate
※2019年5月末時点で 情報です 60
「も づくり」する金融機関
ision
62
インフラ
i / ndroid サーバ
テクノロジーでお金を自動化したい人！
エンジニア採用中！
【重要な注意事項】
● 本資料 、断定的判断を提供するも で なく、情報を提供すること みを目的として
おり、いかなる種類 商品も勧誘するも で ありません。 終的な決定 、お客様
自身で判断するも とし、当社 これに一切関与せず、また、一切 責任を負いませ
ん。
● 本資料に 将来 出来事に関する予想が含まれている場合がありますが、それら
予想であり、また、本資料 内容 正確性、信頼性、完全性、適時性等を一切保証す
るも で ありません。本資料に基づいて被ったいかなる損害についても、当社 一
切 責任を負いません。また、当社 、新しい情報や将来 出来事そ 他 情報に
ついて、更新又 訂正する義務を負いません。
● 本資料を利用することによりお客様に生じた直接的損害、間接的損害、派生的損害そ
他いかなる損害についても、当社 一切 責任を負いません。
商号等：ウェルスナビ株式会社
金融商品取引業者 関東財務局長（金商）第2884号
加入協会：日本証券業協会、一般社団法人 日本投資顧問業協会63
ppendix
● 標準でスナップショット完了 通知機能がないため、 tep unctionにてス
ナップショット処理状況 ポーリング
複製処理 改善（改善後）詳細
tep unction (prod)
(dev)
loud atch
chedule rigger
tatus hecker
lone urora
heck tatus
ubmit atch
lone
ask
nly uccess
tep unction
lone urora
lone
65
awslogs バッファ制約
● loud atch ogsへ 書き込み処理仕様 ※docker-ce/awslogs 実装より
○ 5秒間隔で loud atch に書き込み
○ stdout/stderr が4096イベント以上になった場合 loud atchに書き込み
● つまり、 loud atch ogs に障害が発生したとしても 4096 イ
ベントまで awslogs 側でバッファ可能○ 2019年4月時点で、設定値 固定
○ ocker v19.03から 可変オプションが追加予定
■ ただし argateに搭載される ockerバージョン 非公開
/ argate
ocker
awslogs
コンテナ
stdout/stderr
loud atch ogs
callut og vents
66
ervice iscovery 落とし穴（独自 環境 み）
● 既存 独自 ctive irectory環境で構成された ubnetで
ervice iscoveryが使えず
/サービス設定
loud ap oute 53①webコンテナをweb.localで名前解決できるよう定義
レコード登録指示
ctive irectory
既存 / ubnet
web.local 名前解決をしたいサーバ
mazon rovided
② オプションセット設定によって に問い合わせが行ってしまう
oute 53esolver
③ esolver経由で到達可能だが、ネガティブキャッシュが不可変な
レコード （900秒）に依存する
67