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

Transcript

1. Elixir/Phoenixによる
   Web開発の現場から
   Elixirで宇宙衛星/エッジコンピューティング/Web @マネーフォワードオフィス
   2023/06/22 @ohr486
   

   View Slide

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(光の戦士/白魔道士)
   

   View Slide

3. agenda
   ● Goal
   ● Web開発とは？
   ● 昨今のWeb開発の傾向
   ● Webアプリのライフサイクル
   ● Webアプリのアーキテクチャの推移
   ● SPA or Hotwire
   ● Why Elixir/Phoenix ?
   ● Webアプリのアーキテクチャと開発チームの構造
   ● まとめ
   

   View Slide

4. Goal
   ● ターゲット
   ○ Webアプリの技術選定の指針が欲しい エンジニアマネージャーとプロダクトオーナー
   ○ Webアプリを作りたいエンジニア
   ● 今日のゴール
   ○ Web開発を始める際の技術選定の観点が増えている
   ○ Webアプリのライフサイクルを理解する
   ○ Elixir/Phoenixを採用した時のメリット/デメリットを把握する
   ○ Elixir/Phoenixでサービス開発をしている中での 気づきの共有
   ● 話さないこと
   ○ Elixir/PhoenixによるWebアプリの設計/実装の詳細
   ○ クラウド/インフラの各種マネージドサービスの詳細
   

   View Slide

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
   

   View Slide

6. 昨今のWeb開発の傾向
   ● 開発期間が短い
   ○ 数ヶ月である程度のクオリティのサービスをゼロから作る事が求められる
   ● 小規模なチーム開発
   ○ インフラ、サーバー、クライアントをある程度兼任
   ○ 少人数チームで短期に開発
   ● リッチなクライアント
   ○ SPAから徐々にHotwireに
   ● インタラクティブ/リアルタイムWeb
   ○ WebSocket
   ● トラフィックがピーキー
   ○ トラフィックのスパイク（通常の数倍〜数十倍）に耐えられる
   ● 開発/運用フェーズによってスケールイン/アウト
   ○ スケールイン/アウト、スケールアップ/ダウン可能な構成
   ● DevOps/自動化による効率的な運用
   ○ CI/Deploymentの自動化
   ○ インフラやクラウドに依存しがち
   

   View Slide

7. Webアプリのライフサイクル
   ● 企画
   ○ デザイン/モックのみ
   ● プロトタイプ版(MVP/β)
   ○ 数人〜程度のユーザー
   ○ サーバー1台に全部載せ
   ● リリース版(ローンチ)
   ○ サーバーは冗長化/スケーリング構成
   ○ ローンチ直後のスパイクを見込んでサーバーリソースは過剰気味、ローンチ終了後に縮退
   ● リリース版(成長期)
   ○ サービスの成長に合わせて、サーバーリソースを拡充
   ○ 負荷的な問題が発生し、作りが悪いとリアーキテクチャを強いられる
   ● リリース版(縮退期)
   ○ ユーザー数や売上の減少に伴い、コスト圧縮が強いられる
   ○ 通信費の見直し、売上の5%程度が一般的な適正値だが、カット対象になりうる
   ● クローズ
   ○ サービスの継続性が担保できなくなれば、サービス終了
   ○ データをバックアップしクローズ
   

   View Slide

8. Webアプリのアーキテクチャの推移(企画)
   モック
   ユーザー
   ブラウザ
   

   View Slide

9. Webアプリのアーキテクチャの推移(プロトタイプ)
   Linuxサーバー
   ユーザー
   ブラウザ
   HTTP
   サーバー
   DB
   Webアプリ
   

   View Slide

10. オートスケール/オーケストレーション
    Webアプリのアーキテクチャの推移(ローンチ)
    Linuxサーバー/コンテナ
    ユーザー
    ブラウザ
    HTTP
    サーバー
    DBサーバー
    Webアプリ
    ロードバランサー
    

    View Slide

11. オートスケール/オーケストレーション
    Webアプリのアーキテクチャの推移(機能拡充)
    Linuxサーバー/コンテナ
    ユーザー
    ブラウザ
    HTTP
    サーバー
    DBサーバー
    Webアプリ
    ロードバランサー
    Linuxサーバー/コ
    ンテナ
    Job
    SPA
    Hotwire
    RT-Web
    

    View Slide

12. オートスケール/オーケストレーション
    Webアプリのアーキテクチャの推移(成長期)
    Linuxサーバー/コンテナ
    ユーザー
    ブラウザ
    HTTP
    サーバー
    DBサーバー
    (Primary)
    Webアプリ
    ロードバランサー
    DBサーバー
    (Replica)
    write read
    KVS/Cache
    cache
    Linuxサーバー/コ
    ンテナ
    Job
    SPA
    Hotwire
    RT-Web
    

    View Slide

13. オートスケール/オーケストレーション
    Webアプリのアーキテクチャの推移(縮退期)
    Linuxサーバー/コンテナ
    ユーザー
    ブラウザ
    HTTP
    サーバー
    DBサーバー
    (Primary)
    Webアプリ
    ロードバランサー
    read/write
    Linuxサーバー/コ
    ンテナ
    Job
    SPA
    Hotwire
    RT-Web
    

    View Slide

14. Webアプリのアーキテクチャの推移
    ● Webアプリのアーキテクチャの技術要素/コンポーネント
    ○ HTTPサーバー / Appサーバー / DBサーバーの分離
    ○ ロードバランサによるトラフィック分散
    ○ 非同期処理(Job)のミドルウェア
    ○ キャッシュの機構
    ○ DBの分散（参照分散）
    ○ スケーリング機構(スケールアウト/イン、スケールアップ /ダウン)
    ● それぞれのフェーズで、上記の技術的要件が変動する
    ○ これらの技術要件を担保できなければ、リアーキテクチャ（作り直し）が強いられる
    ○ なるべく基本構成を変えずに 、これらの要件に対応したい
    ⇨Elixir/Phoenixを採用する事で、比較的少ない変更で対応できる
    

    View Slide

15. SPA or Hotwire
    ● (従来の)SPA(Single Page Application)
    ○ アプリをクライアントサイドとサーバーサイドに分離
    ○ サーバーサイドはクライアントから利用できる JSONを返却するAPIを提供
    ○ クライアントサイドは JavaScriptで上記APIを使って画面を描画
    クライアントサイド
    フロントエンドアプリケーション
    サーバーサイド
    JSON
    受け取ったJSONでDOMを
    JavaScriptで構築
    ※ 状態管理やバリデーションはクラ
    イアント側で行う必要がある
    ※ バックエンドとフロントエンドで
    2つ
    のアプリを作る事になる
    

    View Slide

16. SPA or Hotwire
    ● Hotwire(HTML Over The Wire)
    ○ サーバーサイドのみで SPA風のアプリケーション開発が可能
    ○ サーバーサイドから JSONの代わりにHTMLをクライアントに返却
    ○ クライアントサイドは Hotwireのライブラリがクライアントから HTMLを受け取り現在のページの要素
    を差し替える
    クライアントサイド
    Hotwireライブラリ
    サーバーサイド
    HTML
    受け取ったHTMLで画面の要素を差
    し替える(JavaScript実装不要)
    ※ 状態管理やバリデーションはサー
    バーだけで良い
    

    View Slide

17. SPA or Hotwire
    ● チーム構成
    ○ SPAの開発にはwebフロントに関する技術スタックが必要
    ○ バックエンドとフロントエンドの技術は毛色がかなり異なるので少人数のチームほど Hotwireのメリッ
    トが出やすい
    ● 開発効率
    ○ SPAの場合、フロント/バックエンド、2つのアプリを開発する事になる
    ○ ただし、Hotwireに比べてSPAのほうが柔軟に画面を実装できる
    ● 結局どっちが良いの？
    ○ Hotwireはまだ比較的新しい技術なので十分枯れてるわけではない、一方 React/Vue.js等の従来
    のSPAアーキテクチャは関連情報が多く安心感がある
    ○ webフロントエンジニアがチームに居れば (従来の)SPA、いなければHotwireに(我々は)している
    ⇨Phoenix/LiveViewを採用する事でHotwireを実現できる
    

    View Slide

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だけ)になるのでインフラ領域のエンジニア負荷が下
    がる
    

    View Slide

19. Why Elixir/Phoenix? / スケールアップ時の特性
    Linuxサーバー/コンテナ
    カーネル/OS/ハードウェア
    ErlangVM
    scheduler
    …
    Linuxサーバー/コンテナ
    カーネル/OS/ハードウェア
    ErlangVM
    scheduler
    …
    スケールアップ
    (サーバーspec up)
    CPUコア数に応じて増加
    スケジューラーを跨いでプロセスは適切
    に分散配置/マイグレーション
    プロセス(OSのプロ
    セスではない)
    VM内のプロセスス
    ケジューラー
    性能は比較的線形
    に近い形で向上す
    る
    Rails/Spring/LaravelでLinuxサー
    バー/コンテナのspecを倍にするケース
    を考えてみる
    ⇨ 適切なプロセス/スレッド数、メモリ、そ
    の他設定の最適値は？
    ⇨ 最適な性能を出すには、なんだかんだ
    でプランニング/計測をやり直す必要があ
    る
    

    View Slide

20. Why Elixir/Phoenix? / Elixirアプリの実体(プロセス群)
    ErlangVM Application Controller
    Application
    Application Master
    Phoenix サブシスA Elixir
    …
    ErlangVM上のアプリ(のプロセス群)は同
    レベルでクラスタリングされている
    Elixir(言語ランタイム)もErlangVM上では
    (ただの)アプリとして存在する
    Erlang/Elixirで実装されているサブシスで
    あれば、ErlangVM内で拡張可能
    (Elixirアプリとして追加すれば良い
    )
    ErlangVM内で完結するので、アーキテク
    チャに変更を加えず機能拡張ができる
    

    View Slide

21. Why Elixir/Phoenix? / Phoenixの実体(プロセス群)
    Application Application Master
    HTTPサーバー
    モジュール
    (Cowboy)
    Jobシステム
    (Exq)
    Phoenixアプリに
    組み組んでいるモ
    ジュール
    (Lib単位で管理)
    Phoenixアプリの機能はプロセス
    treeの一
    部としてアプリに組み込まれる
    ex) HTTPサーバー、Jobシステム、etc
    Elixirのライブラリ/パッケージとして管理さ
    れていれば、Phoenixアプリの関連パッ
    ケージとして設定するだけで、組み込み
    /
    拡張できる
    ErlangVM内/Phoenixアプリ内で完結す
    るので、アーキテクチャに変更を加えず機
    能拡張ができる
    

    View Slide

22. Webアプリのアーキテクチャと開発チームの構造
    ● コンウェイの法則
    ○ システム設計/アーキテクチャは、組織構造を反映させたものになる
    ● コンウェイの法則の逆転現象
    ○ システム設計/アーキテクチャを変更する方が組織構造を変更するより難しい場合、組織の構造は
    システム設計/アーキテクチャの構造に影響をうける(その結果組織構造が変容する )
    ● 少人数チーム、短納期で開発したい場合、組織構造を複雑にしたくない(OHを増や
    したくない)
    ⇨Elixir/Phoenixを採用する事で、Webアプリのライフサイクルを通して、比較的シ
    ンプルなアーキテクチャに収める事がやりやすくなる
    ⇨組織構造をシンプルに比較的保ちやすくなる(※維持するには言語/技術スタック
    によらずある程度のコストは当然かかる)
    

    View Slide

23. まとめ
    ● Webアプリのライフサイクルと各フェーズにおけるアーキテクチャの一般的な推移
    について紹介しました
    ● Elixir/Phoenixを利用する事で、Webアプリのライフサイクルを通して、比較的楽に
    アーキテクチャをシンプルに保つ事ができる理由を紹介しました
    ● コンウェイの法則により、開発チームの組織構造がどう影響されるかについて紹介
    しました
    ● 以上から、我々の開発チーム、短期かつ小規模でWebアプリを開発する際に、
    Elixir/Phoenixを採用しています
    ● 技術採用の判断材料になれば幸いです
    

    View Slide

24. おわり
    

    View Slide