elixirを プロダクションに 導入する 2022-02-16 EDI#12

agenda ● About Me ● ゴール ● プライベートでの開発とプロダクション導入の違い ● 導入モチベーション ● 弊社事例: 技術選定フロー ● 弊社事例: 適用システム ● まとめ

About Me ● おーはら / Twitter: @ohrdev / Github: ohr486 ● 株式会社ドリコム SRE部 部長 ○ Work: ■ エンジニアマネージャ ● 技術戦略の策定/推進 ● エンジニア採用/採用戦略策定 ■ サーバー/インフラエンジニア ● 開発現場でゲームのバックエンド (Rails/Phoenix/Go/HCL)のコード書いてます ■ 新規事業/ディレクター ● 負荷試験支援/DevOps推進支援/設計コンサル ● Community ○ tokyo.ex / Japan Elixir Association / Erlang&Elixir Fest ● Hobby ○ 仏像制作 ○ 自転車

ゴール ● ターゲット ○ programming elixirを読み終わった人 ○ elixirを本番環境・実業務で採用しようか検討している方 ○ (elixirに限らず)技術選定を行う方 ● 今日のゴール ○ elixirを業務で採用するかの判断基準例・事例を知る ● 話さない事 ○ 具体的な本番環境での設計/実装について ○ ※ 参考文献を参照

プライベート開発とプロダクション導入の違い ● ビジネス課題を解決できるか？ ○ 技術が目的になっていないか？ ○ 運用目線があるか？ ● チーム開発ができるか？ ○ 開発チームの技術スタックにマッチしているか ○ 個人ではなくエンジニアチームとして開発できるか ● プロダクトが成長した時に開発チームがスケールできるか？ ○ エンジニア採用ができるか？ ○ エンジニア育成ができるか？ ● サービス規模 ○ プロダクションレベルのトラフィック・ユーザー規模を想定して検討しているか？ ○ ローカル開発 vs k8sクラスタ上での運用 ○ ローカル開発 vs 無停止運用

導入モチベーション ● なぜelixir(Erlang)なのか？ ○ 無停止運用 ○ 高い可用性 ○ 耐障害性 ○ webサーバーとしての性能 ○ キラーライブラリ(phoenix, liveview, ecto)の存在 ● 組織の技術戦略 ○ オンプレ vs クラウド ○ VM vs k8s/container ○ WAFの有無/種類 ○ 組織構造 ■ インフラ、開発チームが別組織 or 同一組織 ■ SRE部門の有無 ● 組織のエンジニア採用/育成戦略 ○ 中途採用 vs 若手育成 ○ スペシャリスト vs ゼネラリスト

導入モチベーション 👍 ● 無停止でwebサーバーを運用したい ○ hot code swap ● 可用性を高く維持したい ○ ErlangVM ○ OTPによるプロセス管理 ● WebSocketを利用 ○ channelによるwebsocketのハンドリング ● 高い開発効率、生産性 ○ hotwire(liveview) ○ phoenixによる開発 ■ メジャーなWAFを利用したことがあれば、とっつきやすい ○ コスト効率が良い ■ 1台の同一specのサーバーで捌けるトラフィック /コネクション数が比較的大きい ● メンバーの良い業務経験となるか ○ 開発メンバーのキャリア /経歴として胸を張って記載できるか

導入モチベーション 😱 ● コンテナによる運用 ○ ErlangVMとコンテナの相性が悪い ■ ErlangVMをコンテナにバンドルする必要があるので FATになりがち ■ ビルド/静的解析の時間が長い ● エンジニア採用の難易度が高い ○ 経験者は(ほぼ)とれない前提で考えておいたほうが良い ● 運用ノウハウが多言語に比べて比較的少ない ○ Erlang in Anger ○ debug tools

弊社事例: 選定フロー 1. サービスの要件洗い出し a. 開発だけでなく、運用も見据えての要件洗い出し 2. 選定候補の絞り込み a. 同じ要件でも、言語、 WAF、ミドルウェア、インフラそれぞれで実現できうる b. 特定の領域にこだわらない (ex. elixirやphoenixの層でなんでも解決しようとしない 、インフラで担保したほうが楽な要件も多い ) 3. ライブラリ/コミュニティの状況把握 a. 使いたいライブラリ /OSSが充実しているか b. https://github.com/h4cc/awesome-elixir c. 最悪、力技で(自分等で)自前実装できるか 4. エンジニア市場の状況把握 a. 現状の開発組織で 育成まで手が回るか b. 最悪お金で解決できるか /技術顧問がいそうか 5. 性能検証 a. 性能比較 b. ベンチマーキング c. コスト試算 6. ステークホルダーへのプレゼン a. 技術選定の最終決定者 (CTO、技術部門の部門長、 techリード、etc)は誰かを意識 b. 主観的ではなく、客観的に (性能検証結果の 数字で)説明できているか i. 「技術が目的」になっていないか ii. 「ビジネスの成功 」が優先されているか

弊社事例: 適用システム ● 弊社事例 ○ 広告サービスのbackend/api ○ html5ゲームプラットフォームのリアルタイム通信基盤 (chat/message) ○ スマホゲームのバックエンド ○ websocketベースのゲーム通信基盤 ○ ゲームのマッチング /通信サーバー ● 主な要件 ○ 停止させてはいけない /高い可用性を求められるシステム ○ 大量のwebsocketを取り扱いやすいシステム ■ 比較対象: Rails ActionCable ■ アプリ層で、コネクションの再接続、認証を行える

まとめ ● elixirのプロダクション利用までの選定基準・例について説明しました ● 弊社の事例として、elixirの技術選定フローについて紹介しました ● elixirを採用した後の参考文献 ○ https://pragprog.com/titles/tvmelixir/adopting-elixir/ ○ ※ 少し古いです ○ programming elixirの次に読みたい書籍 ■ どう本番にelixirを適用するか