【レポート】【マネーフォワード】800万+人/事業所の金融データを持つ20+サービスのクラウド大移行 #AWSSummit #AWSSummitOsaka

AWS Summit Osaka 2019

#レポート

#AWS

西村祐二

2019.06.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どうも！大阪オフィスの西村祐二です。

2019年06月27日に大阪のグランフロントで開催されていますAWS Summit Osaka 2019で行われたセッション「【マネーフォワード】800万+人/事業所の金融データを持つ20+サービスのクラウド大移行」についてレポートします。

セッション概要

登壇者と概要は以下の通りです。

株式会社マネーフォワード
取締役執行役員 CTO

中出匠哉

株式会社マネーフォワード
サービス基盤本部インフラ部サービスインフラグループ

小笠原純也

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

レポート

マネーフォワードの紹介
- 設立丸7年
- 京都の拠点が2月にできた
- ４つの事業ドメイン
  - マネーフォワードビジネス
    - クラウド会計
    - クラウド確定申告
    - クラウド経費
    - など
    - バックオフィス業務をサポートするサービスを提供
  - マネーフォワードホーム
    - ManeyForward ME
    - 利用者数：800万人突破
    - 家計簿利用率シェアNo1
  - マネーフォワード X
  - マネーフォワード Finance
システムの過去の現状
- 2012年創業時
  - アカウントアグリゲーション基盤を作った
    - 銀行などアカウントを集約するシステム
  - 2012年マネーフォワードMEをリリース。アカウントアグリゲーションのメインDBを利用
  - クラウド会計、クラウド確定申告、クラウド請求書、クラウド給与、クラウド経費、クラウド資金調達など順次多くのサービスをリリース
  - すべてのサービスはメインDBを参照し、超密結合化した状態
インフラの負債に伴う課題
- ビジネスの課題
  - 開発スピードの低下
- インフラの秘伝のタレ化
- 複数のプロダクトが同一サーバで動いている
- 20以上のサービスが全て１つのインフラチームがみている
- 新サービスのたびにインフラチームの負担が増加
- このままだと運用負荷が高まっていくことになる
  - しかし、やることがいっぱい
  - 結果として改善の時間を確保できない
  - 新卒入社の若手がこの課題に取り組んだ
目指したことはスケールしやすい環境作り
- AWSを導入
- インフラチームが運用するものの数を極力へらす
- マネージドサービスを極力使う
  - 運用しなくていいものはしない方針
- Cattle, not pets
  - オンプレとクラウドの扱い方について考え方を採用
アプリケーションの実行環境を疎結合に
- 密結合なサービスの相乗りをやめて、アプリケーションごとに分割
- コンテナ化することで疎結合にして他サービスに影響を及ぼさないようにする
- 疎結合にすることでアプリケーションチームの変更に対する心理的障壁も下げる
アプリケーションチームへの権限移譲
- インフラチームが管理する必要のないものは管理しない
  - 言語、バージョン、依存ライブラリなど
- Dockerfileをアプリケーションリポジトリへ
  - 実行環境の管理をアプリケーションチームに移譲
  - ECSの設定等はインフラチームが引続き行い将来的に移譲予定
    - はじめに全て移譲するのは移譲コストがかかり過ぎるため
- IaC
  - インフラのあるべき姿がコードとして残る
  - 同一のコードで複数環境や同じ環境を作成できる
  - Pull Requestを通じて、環境変更に対するレビューができる
    - オペミス等による変更を防ぐ
  - インフラのブラックボックス化を防ぐ
AWSを選んだ理由
- 豊富なマネージドサービス
  - RDB系はマネージドサービスが決め手
  - マネーフォワードのサービスではDBがキモなので
- ほぼすべてのリソースはAPIで操作可能
- Pay−as−you−goモデル
  - 必要なときに使った分だけ支払うモデルがマッチ
AWS移行プロジェクト
- IaCによるインフラの宣言的理解
  - TerraFormを選択
  - 社内による利用実績があった、OSS、ドキュメントも充実
  - AWS以外のサービスも同じように管理できる
    - Datadogなど
  - TerraFormの有料サービスを利用している
    - stateの管理
    - GitHubと連携してplan/applyの自動化
    - クレデンシャル管理
    - チームベースでのアクセス管理
    - Remote plan
    - など
- AWS Direct Connetを用いた漸進的マイグレーション
  - オンプレのプロダクトの大半はメインDBに依存している状況
    - 20+のサービスを同時に移行は非現実的
- スモールプロダクトでプロトタイピング
  - まずは新規プロダクトのリードタイム短縮にフォーカス
  - インフラのスモールスタート
    - ECSから始めた
    - EKSもこれから移行を予定
    - 当時は学習コストや安定性などを考慮してECSを選択
  - 見えてきた課題
    - 新規構築時の大量のボイラーテンプレート
    - レビューコスト増大
    - =>モジュール化することでコスト削減
      - Teraform Service Modules
      - 200行から5行に
- クラウド経費サービスをはじめに移行対象にした
  - 2016年にリリースしており、4年目
  - メインDBに大きく依存
  - テスト環境での移行
    - テスト環境ではうまくいっていた
      - ただ北海道<=>東京でDX経由でRTTが約20ms
    - 実際には予想以上にレイテンシが増加、ユーザ体験が悪化
    - 現状参照分割がうまくいってない
    - DXを使っても光の速度には勝てない
- スモールプロダクトからはじめ、スケールする方法を模索は成功
  - 6ヶ月で10+の新規アプリケーションを構築