Upgrade to Pro — share decks privately, control downloads, hide ads and more …

elixirをプロダクションに導入する

ohr486
February 16, 2022

 elixirをプロダクションに導入する

ohr486

February 16, 2022
Tweet

More Decks by ohr486

Other Decks in Programming

Transcript

  1. agenda • About Me • ゴール • プライベートでの開発とプロダクション導入の違い • 導入モチベーション

    • 弊社事例: 技術選定フロー • 弊社事例: 適用システム • まとめ
  2. About Me • おーはら / Twitter: @ohrdev / Github: ohr486

    • 株式会社ドリコム SRE部 部長 ◦ Work: ▪ エンジニアマネージャ • 技術戦略の策定/推進 • エンジニア採用/採用戦略策定 ▪ サーバー/インフラエンジニア • 開発現場でゲームのバックエンド (Rails/Phoenix/Go/HCL)のコード書いてます ▪ 新規事業/ディレクター • 負荷試験支援/DevOps推進支援/設計コンサル • Community ◦ tokyo.ex / Japan Elixir Association / Erlang&Elixir Fest • Hobby ◦ 仏像制作 ◦ 自転車
  3. ゴール • ターゲット ◦ programming elixirを読み終わった人 ◦ elixirを本番環境・実業務で採用しようか検討している方 ◦ (elixirに限らず)技術選定を行う方

    • 今日のゴール ◦ elixirを業務で採用するかの判断基準例・事例を知る • 話さない事 ◦ 具体的な本番環境での設計/実装について ◦ ※ 参考文献を参照
  4. プライベート開発とプロダクション導入の違い • ビジネス課題を解決できるか? ◦ 技術が目的になっていないか? ◦ 運用目線があるか? • チーム開発ができるか? ◦

    開発チームの技術スタックにマッチしているか ◦ 個人ではなくエンジニアチームとして開発できるか • プロダクトが成長した時に開発チームがスケールできるか? ◦ エンジニア採用ができるか? ◦ エンジニア育成ができるか? • サービス規模 ◦ プロダクションレベルのトラフィック・ユーザー規模を想定して検討しているか? ◦ ローカル開発 vs k8sクラスタ上での運用 ◦ ローカル開発 vs 無停止運用
  5. 導入モチベーション • なぜelixir(Erlang)なのか? ◦ 無停止運用 ◦ 高い可用性 ◦ 耐障害性 ◦

    webサーバーとしての性能 ◦ キラーライブラリ(phoenix, liveview, ecto)の存在 • 組織の技術戦略 ◦ オンプレ vs クラウド ◦ VM vs k8s/container ◦ WAFの有無/種類 ◦ 組織構造 ▪ インフラ、開発チームが別組織 or 同一組織 ▪ SRE部門の有無 • 組織のエンジニア採用/育成戦略 ◦ 中途採用 vs 若手育成 ◦ スペシャリスト vs ゼネラリスト
  6. 導入モチベーション 👍 • 無停止でwebサーバーを運用したい ◦ hot code swap • 可用性を高く維持したい

    ◦ ErlangVM ◦ OTPによるプロセス管理 • WebSocketを利用 ◦ channelによるwebsocketのハンドリング • 高い開発効率、生産性 ◦ hotwire(liveview) ◦ phoenixによる開発 ▪ メジャーなWAFを利用したことがあれば、とっつきやすい ◦ コスト効率が良い ▪ 1台の同一specのサーバーで捌けるトラフィック /コネクション数が比較的大きい • メンバーの良い業務経験となるか ◦ 開発メンバーのキャリア /経歴として胸を張って記載できるか
  7. 導入モチベーション 😱 • コンテナによる運用 ◦ ErlangVMとコンテナの相性が悪い ▪ ErlangVMをコンテナにバンドルする必要があるので FATになりがち ▪

    ビルド/静的解析の時間が長い • エンジニア採用の難易度が高い ◦ 経験者は(ほぼ)とれない前提で考えておいたほうが良い • 運用ノウハウが多言語に比べて比較的少ない ◦ Erlang in Anger ◦ debug tools
  8. 弊社事例: 選定フロー 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. 「ビジネスの成功 」が優先されているか
  9. 弊社事例: 適用システム • 弊社事例 ◦ 広告サービスのbackend/api ◦ html5ゲームプラットフォームのリアルタイム通信基盤 (chat/message) ◦

    スマホゲームのバックエンド ◦ websocketベースのゲーム通信基盤 ◦ ゲームのマッチング /通信サーバー • 主な要件 ◦ 停止させてはいけない /高い可用性を求められるシステム ◦ 大量のwebsocketを取り扱いやすいシステム ▪ 比較対象: Rails ActionCable ▪ アプリ層で、コネクションの再接続、認証を行える