Elixir/PhoenixによるWeb開発の現場から

Transcript

1. Elixir/Phoenixによる Web開発の現場から Elixirで宇宙衛星/エッジコンピューティング/Web @マネーフォワードオフィス 2023/06/22 @ohr486
2. About Me • おーはら / Twitter: @ohrdev / Github: ohr486 • 株式会社ドリコム SREソリューション部 部長 ◦ Work: ▪ エンジニアマネージャ ▪ サーバー/インフラエンジニア ▪ 新規事業/ディレクター • 負荷試験支援サービス • DevOps推進支援/負荷試験/設計コンサル • 月1くらいで社内外のシステムの負荷試験をしている ◦ Background: ▪ Basic / C / Lisp / Java / Ruby / Erlang / Infra / Elixir / Python ◦ ProductionでのElixir利用歴: 10年 ▪ Elixirアプリ: 9サービス( 3サービス現在稼働中、 1サービスリリース予定 ) • Community ◦ tokyo.ex / Japan Elixir Association / Erlang&Elixir Fest ◦ 7/19: tokyo.ex&piyopiyo.ex 合同ハンズオン / HTTPサーバーをスクラッチで作成 (仮) ▪ https://piyopiyoex.connpass.com/event/287674/ • Hobby ◦ 仏像制作, 写経, 寺社仏閣, 自転車, ダイエット ◦ お金/Web3界隈( 長年MoneyTreeを使っていましたが、仮想通貨管理ができないので、 MoneyForwardへ移行 ) ◦ Nerves & Gadget, 自作キーボード ◦ FF11,FF14(光の戦士/白魔道士)
3. agenda • Goal • Web開発とは？ • 昨今のWeb開発の傾向 • Webアプリのライフサイクル • Webアプリのアーキテクチャの推移 • SPA or Hotwire • Why Elixir/Phoenix ? • Webアプリのアーキテクチャと開発チームの構造 • まとめ
4. Goal • ターゲット ◦ Webアプリの技術選定の指針が欲しい エンジニアマネージャーとプロダクトオーナー ◦ Webアプリを作りたいエンジニア • 今日のゴール ◦ Web開発を始める際の技術選定の観点が増えている ◦ Webアプリのライフサイクルを理解する ◦ Elixir/Phoenixを採用した時のメリット/デメリットを把握する ◦ Elixir/Phoenixでサービス開発をしている中での 気づきの共有 • 話さないこと ◦ Elixir/PhoenixによるWebアプリの設計/実装の詳細 ◦ クラウド/インフラの各種マネージドサービスの詳細
5. Web開発とは？ • Web上(ブラウザ上)で動作するシステム /サービスの開発 • これらのシステムの 運用保守 • Web開発に必要な技術 ◦ プログラミング言語 ▪ フロント • ex) HTML, css, JavaScript, etc ▪ バックエンド • ex) Elixir, Ruby, Go, PHP, Python, Java, etc ◦ Webアプリケーションフレームワーク ▪ よっぽどの事がない限り、フレームワークを利用してサービスを開発する ▪ 開発言語によって異なる • ex) ElixirならPhoenix, RubyならRails, JavaScript/TypeScriptならVue.js, React, etc ◦ データベース ▪ RDB • ex) PostgreSQL, MySQL, etc ▪ KVS • ex) Redis, Memcached, etc ◦ インフラ ▪ クラウド • ex) AWS, GCP, Azure, etc ▪ コンテナ/オーケストレーション • ex) k8s, CloudRun, ECS, AppRunner, ACA, etc
6. 昨今のWeb開発の傾向 • 開発期間が短い ◦ 数ヶ月である程度のクオリティのサービスをゼロから作る事が求められる • 小規模なチーム開発 ◦ インフラ、サーバー、クライアントをある程度兼任 ◦ 少人数チームで短期に開発 • リッチなクライアント ◦ SPAから徐々にHotwireに • インタラクティブ/リアルタイムWeb ◦ WebSocket • トラフィックがピーキー ◦ トラフィックのスパイク（通常の数倍〜数十倍）に耐えられる • 開発/運用フェーズによってスケールイン/アウト ◦ スケールイン/アウト、スケールアップ/ダウン可能な構成 • DevOps/自動化による効率的な運用 ◦ CI/Deploymentの自動化 ◦ インフラやクラウドに依存しがち
7. Webアプリのライフサイクル • 企画 ◦ デザイン/モックのみ • プロトタイプ版(MVP/β) ◦ 数人〜程度のユーザー ◦ サーバー1台に全部載せ • リリース版(ローンチ) ◦ サーバーは冗長化/スケーリング構成 ◦ ローンチ直後のスパイクを見込んでサーバーリソースは過剰気味、ローンチ終了後に縮退 • リリース版(成長期) ◦ サービスの成長に合わせて、サーバーリソースを拡充 ◦ 負荷的な問題が発生し、作りが悪いとリアーキテクチャを強いられる • リリース版(縮退期) ◦ ユーザー数や売上の減少に伴い、コスト圧縮が強いられる ◦ 通信費の見直し、売上の5%程度が一般的な適正値だが、カット対象になりうる • クローズ ◦ サービスの継続性が担保できなくなれば、サービス終了 ◦ データをバックアップしクローズ
8. Webアプリのアーキテクチャの推移(企画) モック ユーザー ブラウザ
9. Webアプリのアーキテクチャの推移(プロトタイプ) Linuxサーバー ユーザー ブラウザ HTTP サーバー DB Webアプリ
10. オートスケール/オーケストレーション Webアプリのアーキテクチャの推移(ローンチ) Linuxサーバー/コンテナ ユーザー ブラウザ HTTP サーバー DBサーバー Webアプリ ロードバランサー
11. オートスケール/オーケストレーション Webアプリのアーキテクチャの推移(機能拡充) Linuxサーバー/コンテナ ユーザー ブラウザ HTTP サーバー DBサーバー Webアプリ ロードバランサー Linuxサーバー/コ ンテナ Job SPA Hotwire RT-Web
12. オートスケール/オーケストレーション Webアプリのアーキテクチャの推移(成長期) Linuxサーバー/コンテナ ユーザー ブラウザ HTTP サーバー DBサーバー (Primary) Webアプリ ロードバランサー DBサーバー (Replica) write read KVS/Cache cache Linuxサーバー/コ ンテナ Job SPA Hotwire RT-Web
13. オートスケール/オーケストレーション Webアプリのアーキテクチャの推移(縮退期) Linuxサーバー/コンテナ ユーザー ブラウザ HTTP サーバー DBサーバー (Primary) Webアプリ ロードバランサー read/write Linuxサーバー/コ ンテナ Job SPA Hotwire RT-Web
14. Webアプリのアーキテクチャの推移 • Webアプリのアーキテクチャの技術要素/コンポーネント ◦ HTTPサーバー / Appサーバー / DBサーバーの分離 ◦ ロードバランサによるトラフィック分散 ◦ 非同期処理(Job)のミドルウェア ◦ キャッシュの機構 ◦ DBの分散（参照分散） ◦ スケーリング機構(スケールアウト/イン、スケールアップ /ダウン) • それぞれのフェーズで、上記の技術的要件が変動する ◦ これらの技術要件を担保できなければ、リアーキテクチャ（作り直し）が強いられる ◦ なるべく基本構成を変えずに 、これらの要件に対応したい ⇨Elixir/Phoenixを採用する事で、比較的少ない変更で対応できる
15. SPA or Hotwire • (従来の)SPA(Single Page Application) ◦ アプリをクライアントサイドとサーバーサイドに分離 ◦ サーバーサイドはクライアントから利用できる JSONを返却するAPIを提供 ◦ クライアントサイドは JavaScriptで上記APIを使って画面を描画 クライアントサイド フロントエンドアプリケーション サーバーサイド JSON 受け取ったJSONでDOMを JavaScriptで構築 ※ 状態管理やバリデーションはクラ イアント側で行う必要がある ※ バックエンドとフロントエンドで 2つ のアプリを作る事になる
16. SPA or Hotwire • Hotwire(HTML Over The Wire) ◦ サーバーサイドのみで SPA風のアプリケーション開発が可能 ◦ サーバーサイドから JSONの代わりにHTMLをクライアントに返却 ◦ クライアントサイドは Hotwireのライブラリがクライアントから HTMLを受け取り現在のページの要素 を差し替える クライアントサイド Hotwireライブラリ サーバーサイド HTML 受け取ったHTMLで画面の要素を差 し替える(JavaScript実装不要) ※ 状態管理やバリデーションはサー バーだけで良い
17. SPA or Hotwire • チーム構成 ◦ SPAの開発にはwebフロントに関する技術スタックが必要 ◦ バックエンドとフロントエンドの技術は毛色がかなり異なるので少人数のチームほど Hotwireのメリッ トが出やすい • 開発効率 ◦ SPAの場合、フロント/バックエンド、2つのアプリを開発する事になる ◦ ただし、Hotwireに比べてSPAのほうが柔軟に画面を実装できる • 結局どっちが良いの？ ◦ Hotwireはまだ比較的新しい技術なので十分枯れてるわけではない、一方 React/Vue.js等の従来 のSPAアーキテクチャは関連情報が多く安心感がある ◦ webフロントエンジニアがチームに居れば (従来の)SPA、いなければHotwireに(我々は)している ⇨Phoenix/LiveViewを採用する事でHotwireを実現できる
18. Why Elixir/Phoenix? • パフォーマンス観点 ◦ スケールアップ(サーバー/コンテナのspecアップ)時に性能が線形に近い形で向上する ◦ キャッシュを外部のRedisやMemcachedに頼らなくてもets(ErlangVMのインメモリDB)で代用できる (こともある) • アーキテクチャ観点 ◦ HTTPサーバー、APPサーバー、非同期処理 (Job)機構、簡易KVS、全てがErlangVM上のプロセス (※OSのプロセスではない )として同じレベルで動作する為、管理対象のミドルウェアは ErlangVMの みでよい ◦ Hotwire(Phoenix LiveView)を採用すれば、サーバーサイドで状態管理 が完結する ◦ WebSocket(Phoenix Channel)を採用すれば、高性能なリアルタイムWebがFWレベルで担保 • 組織設計観点 ◦ Webフロントエンド領域のエンジニアの負荷が Hotwire/LiveViewを利用する事で下がる (ただし、高 度な画面の状態管理ができない等の制約もある ) ◦ サーバー/コンテナ構成がシンプル (ErlangVMだけ)になるのでインフラ領域のエンジニア負荷が下 がる
19. Why Elixir/Phoenix? / スケールアップ時の特性 Linuxサーバー/コンテナ カーネル/OS/ハードウェア ErlangVM scheduler … Linuxサーバー/コンテナ カーネル/OS/ハードウェア ErlangVM scheduler … スケールアップ (サーバーspec up) CPUコア数に応じて増加 スケジューラーを跨いでプロセスは適切 に分散配置/マイグレーション プロセス(OSのプロ セスではない) VM内のプロセスス ケジューラー 性能は比較的線形 に近い形で向上す る Rails/Spring/LaravelでLinuxサー バー/コンテナのspecを倍にするケース を考えてみる ⇨ 適切なプロセス/スレッド数、メモリ、そ の他設定の最適値は？ ⇨ 最適な性能を出すには、なんだかんだ でプランニング/計測をやり直す必要があ る
20. Why Elixir/Phoenix? / Elixirアプリの実体(プロセス群) ErlangVM Application Controller Application Application Master Phoenix サブシスA Elixir … ErlangVM上のアプリ(のプロセス群)は同 レベルでクラスタリングされている Elixir(言語ランタイム)もErlangVM上では (ただの)アプリとして存在する Erlang/Elixirで実装されているサブシスで あれば、ErlangVM内で拡張可能 (Elixirアプリとして追加すれば良い ) ErlangVM内で完結するので、アーキテク チャに変更を加えず機能拡張ができる
21. Why Elixir/Phoenix? / Phoenixの実体(プロセス群) Application Application Master HTTPサーバー モジュール (Cowboy) Jobシステム (Exq) Phoenixアプリに 組み組んでいるモ ジュール (Lib単位で管理) Phoenixアプリの機能はプロセス treeの一 部としてアプリに組み込まれる ex) HTTPサーバー、Jobシステム、etc Elixirのライブラリ/パッケージとして管理さ れていれば、Phoenixアプリの関連パッ ケージとして設定するだけで、組み込み / 拡張できる ErlangVM内/Phoenixアプリ内で完結す るので、アーキテクチャに変更を加えず機 能拡張ができる
22. Webアプリのアーキテクチャと開発チームの構造 • コンウェイの法則 ◦ システム設計/アーキテクチャは、組織構造を反映させたものになる • コンウェイの法則の逆転現象 ◦ システム設計/アーキテクチャを変更する方が組織構造を変更するより難しい場合、組織の構造は システム設計/アーキテクチャの構造に影響をうける(その結果組織構造が変容する ) • 少人数チーム、短納期で開発したい場合、組織構造を複雑にしたくない(OHを増や したくない) ⇨Elixir/Phoenixを採用する事で、Webアプリのライフサイクルを通して、比較的シ ンプルなアーキテクチャに収める事がやりやすくなる ⇨組織構造をシンプルに比較的保ちやすくなる(※維持するには言語/技術スタック によらずある程度のコストは当然かかる)
23. まとめ • Webアプリのライフサイクルと各フェーズにおけるアーキテクチャの一般的な推移 について紹介しました • Elixir/Phoenixを利用する事で、Webアプリのライフサイクルを通して、比較的楽に アーキテクチャをシンプルに保つ事ができる理由を紹介しました • コンウェイの法則により、開発チームの組織構造がどう影響されるかについて紹介 しました • 以上から、我々の開発チーム、短期かつ小規模でWebアプリを開発する際に、 Elixir/Phoenixを採用しています • 技術採用の判断材料になれば幸いです
24. おわり