CDN in Moneyforward

CDN strategy required for FinTech service

Transcript

1. MoneyForward,Inc. 2018/7/24 CDN in MoneyForward. FinTechサービスに求められる安全かつ柔軟なCDN戦略 Yosuke Suzuki
2. Introduction 2 Yosuke Suzuki 　Money Forward Financial,Inc. • Career ◦ 2005~2008 Fujitsu FIP, Inc. ◦ 2008~2014 Simplex Technology, Inc. ◦ 2015~2016 American Family Life Assurance Company of　 Columbus( Aflac ) ◦ 2017.01~2018.05 Money Forward, Inc. ◦ 2018.06~ Money Forward Financial, Inc • SNS ◦ @syou1024(twitter) © Money Forward,Inc.
3. マネーフォワードのご紹介 3
4. Mission/Vision/Value 個人のお金の悩みや不安の解消、事業者の経営改善に貢献し、 日本でNo1の「お金のプラットフォーム」になることを目指しています。 Mission お金を前へ。人生をもっと前へ。 「お金」は、人生においてツールでしかありません。しかし「お金」とは、自身と家族の身を守るため、また夢を実現するために必要不可欠な存在でもありま す。 私たちは「お金と前向きに向き合い、可能性を広げることができる」サービスを提供することにより、ユーザーの人生を飛躍的に豊かにすることで、より良い 社会創りに貢献していきます。 Vision すべての人の、「お金のプラットフォーム」になる。 オープンかつ公正な「お金のプラットフォーム」を構築すること、本質的なサービスを提供することにより、個人や法人すべての人のお金の課題を解決しま す。 Value User Focus 私たちは、いかなる制約があったとしても、常にユー ザーを見つめ続け、本質的な課題を理解し、ユーザー の想像を超えたソリューションを提供します。 Technology Driven 私たちは、テクノロジーこそが世界を大きく変えること ができると信じています。テクノロジーを追求し、それ をサービスとして社会へ提供していくことで、イノベー ションを起こし続けます。 Fairness 私たちは、ユーザー、社員、株主、社会などのすべて のステークホルダーに対してフェアであること、オープ ンであることを誓います。 4
5. 主要サービス BtoC(個人向け)・BtoB(法人向け)の両領域でサービスラインナップを拡充。
6. 話すこと、持ち帰って頂きたいこと © Money Forward,Inc. 6 話すこと • マネーフォワードのサービスにおけるCDN要件 • なぜfastlyなのか？ • コンフィグレーション具体例 • コンフィグのデプロイメントの自動化事例 • 今後、fastlyを使ってやりたいこと • fastlyで不足する事 持ち帰って頂きたいこと • CDNを安全に導入/運用するための考慮点 • fastly導入する場合のデプロイメント自動化の考慮点
7. マネーフォワードが欲しいCDNは？ 7
8. 軽くサービスを紹介します。 8
9. PFMサービス 人々のライフステージに沿って起こるお金の課題を、 “個人のお金” という領域で多くのユーザーと複数の接点を持ちながら、 人生に寄り添って解決していくサービスを提供します。そして、 すべての人の人生をもっと前に進めていきたいと考えています。 個人のあらゆるお金の不安をなくし、 人生をもっと前へ。
10. 2,650社以上の金融関連サービス に対応。金融機関対応数国内No.1 ※！ 連携した口座から自動でデータを 取得、分類、グラフ化します。 レシートを撮影するだけで、 支出の内容が反映できます。 口座連携 自動分類 レシート撮影 *当社調べ (2018年6月末時点) 『マネーフォワード』の特徴
11. 自動家計簿・資産管理サービス『マネーフォワード』 家計簿アプリシェアNo.1。利用者数は650万人を突破(2018年1月)し、 家計簿アプリ利用者の約4人に1人は『マネーフォワード』を利用。
12. SaaSプラットフォーム『MFクラウドシリーズ』 バックオフィス業務における領域を包括的にカバーするサービスを提供する企業向 けSaaS(*) 型サービスプラットフォーム。 *SaaS：Software as a Serviceの略称 (以下同) クラウドコンピューティングの普及を背景に、これまで多額の初期投資を必要としていたシステムを SaaS 形態で提供することで、小規模事業者から大企業まですべての事業者に IT の恩恵をもたらします。
13. AI(人工知能）で 仕訳ルールを学習 3,600以上の口座から 取引データを自動取得 国内No.1 の対応数 取引明細の自動取得 人工知能で学習 マルチデバイス 様々なデバイス上で 利用可能 ※ ※当社調べ (2016年12月末日点) MFクラウド会計の特徴 わずらわしい会計作業を自動化し、生産性を大幅に上げる
14. 会計事務所導入実績 会計事務所様にご利用いただく会計ソフトとしてNo.1シェア確率を目指す。 全国各地の3,000を超える会計事務所様にご利用いただいております。
15. サービスの特性 15 • PFMサービスで、650万ユーザ、数千万リクエスト/日。 • 殆どのページはユーザ毎のページ。 • 扱っている情報はセンシティブ。 • ユーザにセキュリティの不安を抱かせるだけでもNG。 ◦ CDNにありがちな障害「他人のキャッシュ見える」なんて起 こしたら会社存続の危機。絶対避ける。 つまり、 CDNに向いていない(と一般に思われる) サービス群。
16. マネーフォワードに求められる要件 16 CDNを入れて、 • サイトを高速化したい。 • サーバの負荷軽減したい。 • でも無闇にキャッシュさせずに事故は絶対避ける。
17. なぜ、fastlyなのか？ 17
18. fastlyの採用理由 18 • コンフィグレーションが超柔軟 • キャッシュの削除が超高速 • コンフィグ伝搬が超高速 • APIで全ての操作が可能 　⇨これら全てが最重要
19. コンフィグレーションが超柔軟 19 • fastlyのバックエンドはvarnish。 • VCL(varnish configuration Langege)で柔軟に定義可能。 • キャッシュの条件を柔軟に定義できる。 • 以下をOR条件、AND条件で組み合わせて、キャッシュ対象を 制限。 ◦ URLのドメイン名が条件に当てはまるか？ ◦ URLのパスが条件に当てはまるか？ ◦ URLの拡張子が条件に当てはまるか？ ◦ リターンコードが条件に当てはまるか？ ◦ ヘッダー情報が条件に当てはまるか？ • 意図しないキャッシュを無くし、事故を避ける。 • 条件が厳しいことで、安心してアプリ開発できる。
20. キャッシュの削除/コンフィグ伝搬が超高速 20 • 誤ったキャッシュが出来てしまった場合に、素早く削除できる、 素早く設定を変更できることが大切 • 一般にCDNのキャッシュ削除、コンフィグ伝搬は時間がかか る。 ◦ 裏には世界各国のエッジサーバがある。 • fastlyはキャッシュ削除、コンフィグ伝搬が圧倒的に速い。 キャッシュ削除 コンフィグ伝搬 fastly 部分パージなら150ミリ秒 (全キャッシュパージでも 10秒程度。一工夫する と、全キャッシュパージも 150ミリ秒) 数秒〜十数秒 他社事例 A社①90%に対して5秒で、全体には1分 A社②今年5月から5秒になった。 (どちらも部分パージ。これでも相当早くなった） 十数分かかる。
21. APIで操作可能 21 • APIファーストの開発なので、全ての変更がAPIで可能。 • つまり、先に上げた作業を自動化できる。 • Chatbotを使って、Slackからキャッシュ削除なんてことも実装 可能 ◦ 気軽過ぎるのも怖くて、マネフォではそこまでやっていません。 • ただ、Jenkinsのジョブを実行したら、キャッシュ削除、コンフィ グ変更&ロールバック、メンテナンスページへ切り替えとかでき る。
22. fastlyの採用理由まとめ 22 • コンフィグレーションが超柔軟 ⇨セキュリテイ事故のリスクを低減する。 • キャッシュの削除が超高速 • コンフィグ伝搬が超高速 ⇨事故発生時のリカバリが素早く行える。 • APIで全ての操作が可能 ⇨上記を自動化する。
23. 少し話し変わります。 Question. 「キャッシュの条件厳しすぎて、 キャッシュヒット率低くならないか？」 こんな疑問ありませんでしたか？ 23
24. その通り、低いです。 リクエスト全体の9%~30%。 24 マネフォの使い方が特殊で厳し過ぎるだけで、 fastly自体は高キャッシュヒット率が売りのサービスです。 誤解無いように。
25. 25 でも大丈夫。 トラフィック比率で評価すると変わる。 全体の55%~99%のトラフィックが削減
26. Answer 「キャッシュヒット率は低くいが、 トラフィックに占める割合は高く、 十分な効果があった」 まず、サービスの特性を見極めること大事！ 26
27. コンフィグレーション具体例 27
28. キャッシュ制御 © Money Forward,Inc. 28 • /assets/から始まるリクエスト以 外は403で返す。 • 拡張子jpg,png、かつ、バックエ ンドのリターンコードが200の場 合、TTL3時間でキャッシュセッ ト。 • それ以外のリクエストはキャッ シュしない。 sub vcl_recv{ if (req.url !~ "^/assets/”) { error 403 "Forbidden"; } } sub vcl_fetch { if((req.url.ext ~ "(?i)^(jpg|png)$"\ && beresp.status == 200)) { set beresp.ttl = 10800s; set beresp.grace = 10800s; return(deliver); # Cache Setting } return(pass); # Not Cache Setting }
29. キャッシュ有効無効切り替え © Money Forward,Inc. 29 • chache_modeテーブルの「status」 がoffの時はキャッシュしない • chache_modeのvalueは、REST APIを使って簡単に変更可能で、簡単 にON/OFFを切り替えられる。 table cache_mode { "status": "off" } vcl_fetch { # Cache Switch if ( table.lookup(cache_mode, "status") == "off" ) { return(pass); } return(deliver); }
30. ヘッダーコントロール(ResponsHeader) © Money Forward,Inc. 30 table domane_list { "sample1.example.com": "true", "sample2.example.com": "false" } sub vcl_deliver { if ( table.lookup(domane, req.http.host) == "true" ) { set resp.http.X-Robots-Tag = "noindex"; } return(deliver); } • リクエストドメインがdomain_list テーブルのvalueでtrueだった ら、レスポンスヘッダーにnoindx ヘッダーを設定する。 • これで特定のドメインを検索され ないように出来る。
31. ヘッダーコントロール(RequestHeader) © Money Forward,Inc. 31 table app_code_map { "sample1.example.com": "AP001", "sample2.example.com": "AP002" } sub vcl_recv { set req.http.X-App-Type =\ table.lookup(app_code_map, req.http.host); return(lookup) } • バックエンドへのリクエストヘッ ダーに特定のヘッダーをもたせ て上げることが出来る。 • ドメイン名によって付与するヘッ ダーを変更して、バックエンドの アプリの挙動を変えてる。
32. メンテナンスページ切り替え © Money Forward,Inc. 32 • 「sample1.example.com」はtrueな ので、Sorry用のバックエンドに振り分 け、Sorryページが見える。 • 「sample2.example.com」はfalseな ので、バックエンドそのままで、通常 のページが見える。 • mainte_flagのvalueは、REST API を使って簡単に変更可能で、簡単に Sorryページに切り替えられる。 • 条件にClientIPを指定して上げて、特 定のIP以外からはSorryということも 可能。開発中のサイトの通信制御な どにも便利。 # Sorry Page Setting table mainte_flag { "sample1.example.com": "true", "sample2.example.com": "false", } vcl_recv { if ( table.lookup(mainte_flag, req.http.host)\ == "true" ) { set req.http.host = "sorry.example.com"; set req.backend = F_sorry_host; } return(pass); }
33. デプロイメントの自動化 33
34. こんなシステム構成 © Money Forward,Inc. 34
35. プロビジョニングツールの選択肢 © Money Forward,Inc. 35 • ansible？ ◦ あります。 ◦ https://github.com/Jimdo/ansible-fastly • terrafform？ ◦ あります。 ◦ https://www.terraform.io/docs/providers/fastly/index.html • 他には？ ◦ Cookpadの@sora_hさんが開発したcodilyというツールもある。 ◦ https://github.com/sorah/codily ◦ rubyのDSLが使える。
36. Question: どれ使ったらいいのか？ 36
37. Answer: fastlyでやりたいこと次第。 fastlyのコンフィグレーションの分類と共に、 それぞれの特徴を説明します。 37
38. fastly のConfigurationは3分類ある。(僕の勝手な分類。 © Money Forward,Inc. 38 • 環境設定 • イベント設定 • 状態設定 これらをどう使いたいかで、プロビジョニングツールが決まります。
39. 環境設定 © Money Forward,Inc. 39 システム構成に対する設定 • ドメイン名 • バックエンドのアドレス • ヘルスチェック • ロードバランシング設定 など # origine and helth check backend server1 { 　.connect_timeout = 3s 　.port = "1443"; .host = "server1.example.com"; .ssl = true; .ssl_cert_hostname = "server1.example.com"; .ssl_check_cert = always; (略) .probe = { .request = "GET /health_check.html" .timeout = 3s; .expected_response = 200; .interval = 15s; (略) } }
40. イベント設定 © Money Forward,Inc. 40 イベント発生時のアクションを定義する。 イベント例 • バックエンドからデータ取ってくる 際、拡張子.jpg、.pngはキャッシュ 3h • リクエスト受け付けたら、特定のIP からリクエストブロック # jpg & png CacheSetting sub vcl_fetch { if((req.url.ext ~ "(?i)^(jpg|png)$")) { set beresp.ttl = 10800s; set beresp.grace = 10800s; return(deliver); # Cache Setting } return(pass); # Not Cache Setting } # Blacklist acl black_list { “10.192.80.20”/32; # tekitou ip#1 } sub vcl_recv { if( client_ip ~ black_list ){ error 403 "Forbidden"; } }
41. 状態設定 © Money Forward,Inc. 41 • フラグ等の一時的な設定 ◦ メンテナンスフラグ ◦ キャッシュON/OFFフラグ • API一つで簡単にKey,Valueを追加、 削除、変更可 • fastly用語でdictionay 例 • mainte_flagテーブルに対し ドメイン名をKeyにValueを取得しtrueな らバックエンドをSorry用の ホストに変える # Sorry Page Setting table mainte_flag { "sample1.example.com": "true", "sample2.example.com": "false", } vcl_recv { if ( table.lookup(mainte_flag, req.http.host)\ == "true" ) { set req.http.host = "sorry.example.com"; set req.backend = F_sorry_host; } return(pass); }
42. イベント設定の設定方法は２つに分かれる。 © Money Forward,Inc. 42 • Snippet：設定は簡単。複雑なこと出来ない。 ◦ 設定補助により、簡易に設定 ◦ 記載方法に制限はある ◦ アクションを一つ一つ定義する必要がある ▪ あるヘッダーが付いてたら、キャッシュ1時間保持 ▪ IPがブラックリストにあったらブロック ◦ gitリポジトリで管理すると、依存関係が分かりづらい • Custome VCL (オススメ)：複雑なことやりたければコチラ ◦ コンフィグを自由に記載出来、複雑な設定が可能 ◦ アクションを複数まとめて定義出来る ◦ gitリポジトリ上でコンフィグで全体の定義が把握しやすい
43. プロビジョニングツールで出来ること © Money Forward,Inc. 43 ツール名 環境設定 イベント設定 状態設定 ※ Snippet Custom VCL ansible ◦ ◦ × × terrafform ◦ × ◦ × codily ◦ × ◦ ◦ ※ key,valueの値を入れるのは、どれも無理。 　 codilyもテーブルの定義まで。 　 しかし、マネフォのユースケースでは、その方が嬉しい。 　 (状態を変更するのに、プロビジョニングなんてしたくない)
44. 現時点で、fastlyを使い倒すならCodilyがオススメ (一部設定を不要と割り切れれば、お好きなものをどうぞ) © Money Forward,Inc. 44
45. Codilyを使ったプロビジョニング in マネフォ (多分、時間切れで飛ばすので、ご参考に①) © Money Forward,Inc. 45 service "eample" do domain "sample1.example.com" domain "sample2.example.com" backend "my backend" do address "server.example.com" end vcl "Main" do content file: "./vcl//main.vcl" main true end dictionary "mainte_flag" end 環境設定はcodlyのDSLに定義 イベント設定はカスタム VCLベタ書き。 codilyから呼び出すのみ 状態設定は、箱だけ作成 $ codily --apply -f recipe.rb recipe.rb
46. CodilyのRecipe ベストプラクティス (多分、時間切れで飛ばすので、ご参考に②) © Money Forward,Inc. 46 recipe | --- recipe.rb ： codilyで指定するDSLファイル | --- variables ： レシピで利用する変数を設定 | `--- service_1.rb ： サービス1の変数定義ファイル | `--- service_2.rb ： サービス2の変数定義ファイル ` --- vcl ： レシピから呼び出すVCL | --- common ： 共通利用するVCLを保存 | --- service_1　 ： サービス1のVCLを保存 | | --- main.vcl ： メインVCL | ` --- include.vcl ： メインVCLから呼び出されるVCL ` --- service_2 ： サービス1のVCLを保存 ※サービスとは、Fastlyの定義の単位です。サービス毎に設定できる
47. fastlyのデプロイメントまとめ 47 • プロビジョニングツールによって、できる事、できない事があ る。 • ツールの選定には、fastlyのコンフィグ分類を意識すると良い。 ◦ 環境設定 ◦ イベント設定 ◦ 状態設定
48. 今後、fastlyを使ってやりたいこと 48
49. 新しい仮想通貨取引所のサービスでも使うつもり © Money Forward,Inc. 49 • もちろん、今まで以上の慎重さが大前提。 • fastlyのWAF機能入れたい ◦ 取引所のシステムはGCP使う。GCPとfastlyの相性は抜 群。(フロントの大量のログを捌くにはBigQueryは最高で す) ◦ fastlyとGCP間は閉域網でInternetを介さない。 • Push通信をfastly経由にしたい ◦ 仮想通貨の板情報は、かなりの負荷が見込まれる。 ◦ 同じ情報を皆んなにリアルタイム配信。 ◦ SSEを使って、fastly経由で配信したい。
50. fastlyの残念なところ 50
51. • Provisionigツールの最新API対応が遅い。 ◦ ユーザに任されてる。fastly社に推進して欲しい。 ◦ ただ、カスタムVCLに多くの事を任せているお陰もあって、 今は困ってはいないです。 • コンフィグレーションが柔軟で、色々なことが出来すぎる ◦ しっかり理解してないと意図しない動作するかも？ ◦ 色々出来て、楽しくなって他の仕事に手がつかな(ry 51
52. まとめ(持ち帰って欲しいこと) © Money Forward,Inc. 52 • CDNを安全に導入/運用するための考慮点 ◦ 適切に制限を掛けられることは大事。 ◦ もしもの時のリカバリ速度も大事。 ▪ 上２つを考えるとfastlyはオススメ。 ◦ サービス特性を見極めてキャッシングする。(キャッシュヒッ ト率低くしても十分効果ある場合もある) • fastly導入する場合のデプロイメント自動化の考慮点 ◦ 各ツールで出来ること、出来ないことがあるので、合ってる ものを選定しましょう。 ◦ コンフィグの区分を意識すると、ツール選定、コーディング がしやすい。
53. クラウド大好き！全てのインフラをコード化してやる！ そんな仲間を募集しています。 MF インフラ https://www.wantedly.com/projects/7727 MFフィナンシャル インフラ　https://www.wantedly.com/projects/191131 ご静聴ありがとうございました！ 53