Upgrade to Pro — share decks privately, control downloads, hide ads and more …

800万+人/事業所の金融データを持つ 20+サービスのクラウド移行 / AWS Migrat...

0gajun
June 27, 2019

800万+人/事業所の金融データを持つ 20+サービスのクラウド移行 / AWS Migration at Moneyforward AWS Summit Osaka 2019

AWS Summit Osaka2019

マネーフォワードでは主要サービスを創業当初からオンプレミス環境で運用しています。7年間でユーザ向けサービス数は20を超え、家計簿サービスの利用者数は800万人を突破する一方で、インフラ起因でのアジリティの低下が目立つようになってきました。この現状を打破し、より多くの価値を速くユーザに届けるために我々はAWSへ移行する事を選択しました。本セッションではマネーフォワードが何故今になってクラウド移行を進める事になったのか、大量の密結合なアプリケーションをどのように移行しているのかについて紹介します。

0gajun

June 27, 2019
Tweet

More Decks by 0gajun

Other Decks in Technology

Transcript

  1. 自己紹介 3 中出 匠哉(なかで たくや) 取締役 執行役員 CTO • 2001年

    ジュピターショップチャンネルに入社 24時間365日生放送でテレビ通販する会社 注文管理システムの開発&運用グループのマネージャー • 2007年 シンプレクス株式会社に入社 金融機関向けにシステムを提供している会社 株式やFXの取引システムの開発&運用のプロジェクトマネージャー FXのディーリングシステムのアーキテクト&プロダクトオーナー • 2015年 株式会社マネーフォワードに入社 家計簿サービス開発部長、技術部(CTO室の前身)部長などを歴任 2016年からCTOに就任
  2. 拡大する事業領域 4つの事業ドメインで事業を展開しています。 提供サービスは50以上 (for xx銀行等 を含む) 8 すべての人生を、 便利で豊かにする。 ビジネスの成長を加速させる。

    パートナーと共に、 新たな金融サービスを創出する。 お金をいい方向へと動かす。 記帳代行自動化サービス クラウド経営分析ソフト くらしの経済メディア 自動家計簿・資産管理サービス 金融商品の比較・申し込みサイト 自動貯金アプリ クーポンアプリ for ◦◦ 金融機関お客様向け自動家計簿・ 資産管理サービス デジタル通帳 金融機関お客様向け通帳アプリ MF Unit 金融機関のアプリへの 一部機能提供 企業間後払い決済サービス AI融資審査モデルの開発 バックオフィス向け 業務効率化ソリューション お金を前へ。人生をもっと前へ。 Business Financial Management 法人向け資金管理サービス
  3. 金融機関との連携(個人向けサービス) 14 群馬銀行 栃木銀行 大光銀行 東邦銀行 京都信用金庫 筑波銀行 北陸銀行 北洋銀行

    みちのく銀行 千葉銀行 JAバンク 第四銀行 中国銀行 滋賀銀行 大光銀行 仙台銀行 ジャルカード 『マネーフォワード for ◯◯』 金融機関お客様向けマネーフォワードを開発 『デジタル通帳』   金融機関お客様向け通帳アプリを開発 『MFUnit』シリーズ   金融機関の既存アプリに PFMの各機能を提供 『レンディングマネージャー ※』:融資サービス契約者向けアプリのアドバイス機能を共同開発 ※『レンディングマネージャー』は、株式会社NTTドコモの商標。
  4. マネーフォワードのプロダクトの歴史 16 メインDB アグリ 2012年 最初に『アカウントアグリゲーション基盤』ができる 金融機関から残高情報や 取引明細を取得するため の基盤 秘匿DB

    残高情報や取引明細はメ インDBに保存 ユーザからお預かりしてい る金融機関の認証情報は アクセス制限された秘匿 DBに保存
  5. 構成管理されていないインフラ 29 • 創業時から秘伝のタレ方式で継ぎ足されてきた ◦ ブラックボックス化されたインフラ ◦ 一部構成管理されているものの秘伝のタレの上に追加 ◦ 作り直そうにもあるべき姿がわからずコスト高

    • 数十台、数百台への変更を簡単かつ安全に行うのが困難 ◦ 変更の際に意図しない副作用に対して常に恐怖が伴う ◦ 複数環境に適用するオペレーションコストが高い
  6. 密結合の実行環境 30 • 複数のプロダクトが同一のサーバーで動いている • メリット ◦ リソースの使用効率がよい ◦ 管理対象のサーバーが減る

    • デメリット ◦ プロダクトAが行いたい変更がプロダクトBに影響しうる ◦ 検証コストが高い ◦ 実行環境に対する変更の権限移譲が簡単ではない
  7. インフラへの権限集中 31 • 20以上のサービス全てを1つのインフラチームが見ている • 責任範囲はアプリケーションコード以外全て ◦ RubyやJREなどの実行環境 ◦ ImageMagickなどの依存ライブラリ

    ◦ Nginx, MySQL, etc… • 全ての変更にインフラチームの作業が必要になってしまう ◦ RubyやJREのver. up でさえもインフラがボトルネックに ◦ リダイレクト設定とかもすべて要インフラ作業 ◦ SaaSの管理も...
  8. 開発要求の増加 33 • 毎年いくつかの新サービスの為のインフラが必要 • スケールアップ/スケールアウトも必要 • パフォーマンスチューニングも必要 • ミドルウェアの切り替え等の対応も必要

    • 脆弱性への対応も必要 • バージョンアップも必要 • 突発的に訪れる障害の対応も必要 • アカウントの管理も必要 • 設計段階からアーキテクトに入る事も必要
  9. 開発要求の増加 34 • 毎年いくつかの新サービスの為のインフラが必要 • スケールアップ/スケールアウトも必要 • パフォーマンスチューニングも必要 • ミドルウェアの切り替え等の対応も必要

    • 脆弱性への対応も必要 • バージョンアップも必要 • 突発的に訪れる障害の対応も必要 • アカウントの管理も必要 • 設計段階からアーキテクトに入る事も必要 • 開発環境の維持/改善も必要! • 関係者との調整も必要!! • SOC/Pマーク... 等の対応も必要!!! • お客様からのヒアリングシートの対応も必要!!!! • 新規機能/サービスの検証も必要!!!!! • 上司への説明も必要!!!!!! • 運用オペレーションも忘れないでね!!!!!!!
  10. 自己紹介 38 小笠原純也(おがさわら じゅんや) @0gajun • 2012-2018年 大学・大学院で研究しながらマネーフォワードを含む 数社でインターン 大学ではハイパーバイザの

    Hardening に関する研究 インターンでは Android を書いたり、ミドルウェアを作ったり、インフラをやったり • 2018年 マネーフォワードに新卒入社 サービスインフラチームに所属 Jenkins から CircleCI へ移行する CI 環境改善やオンプレミス環境から クラウド環境への移行を推進 今回話すプロジェクトのリードをやっています
  11. Infrastructure as Code 45 1. インフラのあるべき姿がコードとして残る ◦ 変更履歴を見れば変更背景も追跡できる 2. 同一のコードで複数環境や同じ構成を作成できる

    ◦ 怠惰でかつ、ミスを起こしやすい繰り返し作業削減 ◦ 環境差異が最小限に 3. Pull Request を通じて、変更に対するレビューができる ◦ オペレーションミス等による意図しない変更を防ぐ インフラのブラックボックス化を防ぎ、 オペレーションコストも削減する
  12. AWSを選んだ理由 46 1. 豊富なマネージドサービス ◦ 特に RDB 系のマネージドサービスが決め手 2. ほぼすべてのリソースを

    API で操作可能 ◦ Infrastructure as Code の実現 3. Pay-as-you-go モデル ◦ 必要なときに使った分だけ払えば良い ◦ 数TBのディスク/数百GBのメモリを持ったVMでさえ!
  13. AWS移行プロジェクト 48 • 2018年下旬に、全既存プロダクトをオンプレ環境からAWS へ 漸進的に移行するプロジェクトを発足 ◦ 既存インフラの負債返済を目指す ◦ インフラチームの約4名で運用と並行してスタート

    • やらなければならないことは主に以下の2つ ◦ テラバイト級の共有 DB 分割と弱体化 ◦ 既存アプリケーションを AWS 上で動作可能にする • 今回は後者の話をご紹介
  14. AWS移行プロジェクト 49 1. Infrastructure as Code によるインフラの宣言的管理 2. AWS Direct

    Connect を用いた漸進的マイグレーション 3. スモールプロダクトでプロトタイピング 4. 既存アプリケーションの移行
  15. AWS移行プロジェクト 50 1. Infrastructure as Code によるインフラの宣言的管理 2. AWS Direct

    Connect を用いた漸進的マイグレーション 3. スモールプロダクトでプロトタイピング 4. 既存アプリケーションの移行
  16. Infrastructure as Codeによるインフラの宣言的管理 51 • Terraform ◦ OSS で開発が活発、ドキュメントも充実 ◦

    社内でも利用実績あり ◦ AWS 以外も同じように Terraform で管理ができる ▪ ex) Datadog, PagerDuty, etc... • チームで利用するために Terraform Enterprise を採用
  17. Terraform Enterprise (TFE) 52 • Terraformを企業で便利に利用するための有償ツール ◦ stateの管理 (最近無料化 ◦

    GitHubと連携してplan/applyの自動化 ◦ クレデンシャル管理 ◦ チームベースでのアクセス管理 ◦ Remote plan etc... • 最初はCircleCI で自作も考えたがセキュリティ面で断念 ◦ Terraform user のクレデンシャル管理に課題
  18. Infrastructure as Codeによるインフラの宣言的管理 53 1. Terraform でインフラのあるべき姿を宣言的に記述 2. GitHub で

    Code Review & Terraform Enterprise で plan 3. 問題なければ Terraform Enterprise で AWS に apply 1. Write code & Pull Request 2. Review code 3. Terraform plan 4. Terraform apply to test Test Account Prod Account 5. Terraform apply to production
  19. AWS移行プロジェクト 54 1. Infrastructure as Code によるインフラの宣言的管理 2. AWS Direct

    Connect を用いた漸進的マイグレーション 3. スモールプロダクトでプロトタイピング 4. 既存アプリケーションの移行
  20. AWS Direct Connectを用いた漸進的マイグレーション 55 • オンプレ環境のプロダクトの大半はメインDBに依存 ◦ 20+サービスの同時移行は非現実的 • 漸進的な移行のためにハイブリッドクラウドを選択

    ◦ AWSとオンプレミスを専用線でプライベート接続 ◦ ジッタの削減やセキュリティ面の懸念を排除 ◦ 1サービスずつの移行が可能に
  21. AWS移行プロジェクト 56 1. Infrastructure as Code によるインフラの宣言的管理 2. AWS Direct

    Connect を用いた漸進的マイグレーション 3. スモールプロダクトでプロトタイピング 4. 既存アプリケーションの移行
  22. インフラもスモールスタートに 58 • 学習と運用コストが低い Amazon ECS から始めた ◦ 将来的には Kubernetes

    を使いたいと思いつつも、 本当 に必要であると実感するまで見送ることに ▪ Amazon EKS も東京リージョンに来ていなかったので、 運用コストが跳ね上がることが見込まれた ◦ また、新しい人が次々入ってくる予定だったため、キャッチ アップコストを抑える目的も Amazon ECS
  23. Terraform Service Modules 59 • 新規構築を繰り返す中で以下の問題が見えてきた ◦ 新規構築時の大量のボイラープレートコード ◦ レビューコストの増大

    • この課題を解決するために、ECS 上での構築を簡単にする Terraform の module を作成 ◦ プロトタイピングを繰り返すことで見えたインフラアーキテ クチャの共通部分のパッケージ化 ◦ 構築コスト及びレビューコストが大幅に削減
  24. Terraform Service Modules 60 • 5つの module を作成 ◦ サービスの要件に応じて組

    み合わせて利用 • 例 ) iam module ◦ 200行からたった5行の レ ビューで済むように
  25. AWS移行プロジェクト 62 1. Infrastructure as Code によるインフラの宣言的管理 2. AWS Direct

    Connect を用いた漸進的マイグレーション 3. スモールプロダクトでプロトタイピング 4. 既存アプリケーションの移行
  26. 既存アプリケーションの移行 64 • “マネーフォワード クラウド経費” の特徴 ◦ 2016年初頭にリリースして4年目のプロダクト ◦ テラバイト級の共有メインDBに強く依存

    ▪ マネーフォワードの大きな負債 ▪ 大半のサービスがメインDBに密結合 ▪ 他プロダクトも依存しているため、メインDBを 経費と 同タイミングで移行することはできない ◦ いくつかのマイクロサービスにも依存
  27. うまく行ったと思われた...が... 67 • 予想以上にレイテンシが増加し、ユーザ体験が悪化 ◦ 一部画面でDX経由のDBアクセスが多く発生 ◦ 現状参照分割が十分でなく、更なる分割の時間は近いう ちには取れない •

    本番投入は... ◦ 共有DBから経費DBを分離するプロジェクトが動いている のでそれを待ってDBと一緒に移行することに... (本当は、今日までに本番投入している予定でした...)
  28. まとめと今後 70 • インフラチームがボトルネックとならないインフラを  目指すた め、オンプレミスから AWS への移行を始めた ◦ マネージドサービスの活用 ◦

    アプリケーションの実行環境分割とチームへの権限移譲 ◦ Infrastructure as Code • スモールプロダクトから始め、スケールする方法を模索 ◦ 6ヶ月で10+の新規アプリケーションを構築できるように ◦ Ruby の ver. up 等もインフラが関わる必要が無くなった ◦ ECS, Aurora, ElastiCache により運用負荷も増えていない
  29. まとめと今後 71 • 既存の移行に関しては移行計画が甘かった ◦ 北海道⇔東京間の RTT 20ms を認識してはいたものの軽視 ◦

    悩むぐらいならとりあえずやってみる。で進んだが、  事前に 20ms の RTT を加えた環境でテストするべきだった ▪ 若気の至り • DX を使っても光の速度には勝てない ◦ 事前にレスポンスタイムの悪化を見積もる ◦ メインDB への依存度の低いサービスから移行する ◦ 依存度の高いサービスは DB 分割 or 参照分割を行い、レ スポンス悪化を防ぐ