elixir-conf-japan-2017-session-ohr486

Copyright Drecom Co., Ltd. All Rights Reserved. 1

Rubyist |>(^o^)|> Alchemist

〜 Elixirの採用からサービス稼働までの記録〜

ElixirConfJapan 2017株式会社 Drecom 大原常徳


AboutMe⁃ Tsunenori Oohara(おーはら ,ohr486)

⁃ Twitter: @ohrdev⁃ tokyo.ex: 主催・運営⁃ ElixirConfJapan: 幹事チーム・運営⁃ JapanElixirAssociation: 理事

⁃ 株式会社ドリコム⁃ 基盤技術部⁃ 全社基盤システム、広告系サービス全般⁃ Elixir/Phoenixアプリを本番で開発・運用 (約2年

⁃ SoftwareDesign2016/11,12⁃ [関数型言語 ]Elixirの始め方 (前後 )


発表の趣旨

⁃ ターゲット⁃ Elixirの導入を検討している⁃ プロダクションで Elixirを使いたい⁃ 中規模以上の Elixirアプリを書いた事がない

⁃ Elixirを使いたくなった⁃ ゴール

⁃ 導入の為に、導入後に、どういう事をするべきかをざっくりと把握する

⁃ 習得の為に何をすれば良いか把握する


発表の趣旨

⁃ 話すこと⁃ 導入事例⁃ 導入の為にしたこと⁃ 失敗、知見⁃ 日本の Elixirコミュニティ事情

⁃ 話さないこと⁃ 前後のセッションで話した・話すテーマ

⁃ Elixirの採用理由 (何故 Elixirなのか⁃ ErlangVM


導入事例紹介

⁃ 組織 /チーム⁃ 社内に Rubyエンジニア多数 (90%Rails製⁃ 開発チームは 5人 (自分以外は Elixir未経験

⁃ プロダクト⁃ 広告サービス基盤⁃ Railsアプリのリプレースプロジェクト

⁃ 期間⁃ 開発 : 6ヶ月⁃ 運用 : 1年半 (うち 1年、新旧サービスを並行稼働 )


導入事例紹介

⁃ リプレースにあたっての要件⁃ サービスを絶対に停止してはいけない

⁃ 導入戦略⁃ マイクロサービス化する⁃ 一部の (API)マイクロサービスから徐々に適用

⁃ AWSに乗る (スケールアップ /アウト機構


App(Rails)App(Rails)

アーキテクチャ

⁃ before

cache

App(Rails)

DB(MySQL)

queue(Redis) Batch(sidekiq)

止めてはいけないが！

site req

api req


API(Elixir)API(Elixir)


⁃ aftercache(Varnish)

Manage(Rails)

DB(MySQL)

queue(Redis) Batch(sidekiq)

API(Elixir)

Front(Rails/js)

DB(Redis)

安定

部分的に replace

徐々に replace

site req

api req



⁃ バッチ /非同期処理⁃ sidekiq: 非同期処理 gem⁃ exq: sidekiqの Elixir実装

Manage(Rails) queue(Redis) Batch(sidekiq)

API(Elixir)

exq’s enqueue

sidekiq’s enqueue sidekiq’s dequeue

ActiveJob I/F


導入事例紹介

⁃ 以上のケースのプロジェクトで⁃ 得られた知見⁃ 失敗⁃ やった事等を、紹介していきます


開発チーミング

⁃ チーミングにあたって注意した事⁃ 求められる Elixir習熟度を意識⁃ 導入者 (知見者 )がボトルネックにならない

⁃ (可能なら )インフラエンジニアを確保する



⁃ 実務に求められるレベル感⁃ Lv.0: 触ったことが無い⁃ Lv.1: コードが読める⁃ Lv.2: 関数が書ける⁃ Lv.3: モジュールが書ける⁃ Lv.4: テストが書ける⁃ Lv.5: 並行処理が書ける⁃ Lv.6: フレームワークを使いこなせる⁃ Lv.7: アプリの設計ができる⁃ Lv.8: チューニング

・書籍・ペアプロ・コードレビュー・各種training

・OTP

・テストツールの理解・プロセスの理解

実務の壁・ ErlangVMの

理解

モックライブラリ (meck)、 E2Eテストツール



⁃ 導入者がボトルネックにならない対策⁃ 静的解析ツールを使ってレビューサポート

⁃ Style Check⁃ dogma⁃ credo

⁃ 静的型解析⁃ Dialyzer

⁃ 自動化 /CI⁃ 自動テスト (ExUnit）⁃ 静的解析を CIに組み込む→初期段階で組み込まなかった為、大量のwarningが発生

⁃ レビューアーを増やす

・ credoのほうがちょっと教育的

・とても遅いので CIで回すのが良い



⁃ レビューアーに求められる知識⁃ Elixirらしいコード⁃ 関数プログラミング⁃ ライブラリの知識 ( 車輪の再発明の回

避 )⁃ awesome-elixir⁃ awesome-erlang⁃ hex.pm

⁃ 並行処理の表現方法⁃ OTPの利用方法⁃ 性能の評価

・既存モジュールが無いか ?



⁃ インフラエンジニアの必要性⁃ Elixirならではのインフラ課題がある

⁃ deploy方法にデファクトが存在しない⁃ exrm(depricated!)/distillery⁃ 無停止更新

⁃ ノード (ErlangVM)のクラスタリング⁃ 監視

⁃ ErlangVMの監視⁃ Supervisorを含むサービスの監視


サービスのスケール

⁃ 「スケール」とは⁃ トラフィックの増加

⁃ ボトルネックポイント



⁃ トラフィックの増加⁃ リリースから 2年で約 50 倍程

⁃ コードの改変無しで対応

⁃ スケールアップ⁃ コア数を増やせば (ある程度 ) 線形に⁃ ErlangVMの恩恵

⁃ スケールアウト⁃ AWSなら ALB、 AutoScalingGroupで対応可



⁃ ボトルネックポイント⁃ データベースへのアクセス⁃ コネクション /プロセスプーリング

⁃ poolboy: https://github.com/devinus/poolboy→Erlangのライブラリ、 Elixirライブラリ内での利用多い→下手なパラメータ設定によっては性能劣化の原因に→pool_size, max_overflow, etc

https://github.com/devinus/poolboy

https://github.com/devinus/poolboy


サービスの運用

⁃ 「運用」とは⁃ 機能開発、テスト⁃ 監視⁃ バージョンアップ



⁃ 機能開発・テスト⁃ TDDで開発⁃ Red-Green-Refactor

⁃ 並行化の列を加えたマトリクス

⁃ 逐次処理・並行処理⁃ Elixirは並行処理を簡単に書けるが、逐

次処理はもっと簡単に書ける（書いてしまう）



⁃ TDD 黄金の回転

きれい

汚い

動かない

動く

RedGreen

Refactor



⁃ TDD 黄金の回転 (並行版 )

きれい

汚い

動かない

動く並行に動く

RedGreen

Refactor

Concurrenize



⁃ 監視⁃ Supervisorがワーカーを再起動するので通常の死

活監視ではサービスの瞬死を完全に検知できない⁃ 1分に 1 回のHeartBeat だとタイミングによってはスルー⁃ →見かけ上は正常なので異常を検知できない

⁃ イベント単位での通知、KPI 値の異常値による検知⁃ Sentry

⁃ https://github.com/getsentry/sentry-elixir⁃ プロセスの crash 時に通知⁃ →通知先 (の sentry) へのDDoSになりかねない

⁃ re:dash⁃ aleart機能

https://github.com/getsentry/sentry-elixir





⁃ バージョンアップの頻度

2014/9/10 2017/3/14

v1.0

R17

v1.4

R19

v1.2

R18

2016/1/1

2014/9/10v1.0

2015/9/25v1.1 2016/1/1

v1.2

2016/6/21v1.3

2017/1/5v1.4

2014/9/10R17.1

2015/6/24R18

2016/6/21R19

2017/4/1v1.4.2

2017/4/1R19.3



⁃ バージョンアップ⁃ Elixir、 Erlang それぞれ別々にバージョンアップ⁃ ただし依存関係あり (ex. Elixir 1.4.2 のコンパイルには、

Erlang R18.0 以上必須 )⁃ →バージョン管理ツールを導入していなかったので、バージョンアップ作業が煩雑

⁃ →kerl, exenvを導入⁃ 目安

⁃ Erlang ：年 1 回のメジャーバージョンアップ⁃ Elixir: 年 2 回のマイナーバージョンアップ

⁃ 環境をイメージ /コンテナにして運用⁃ 特定のバージョン毎のテストやリリースができるように⁃ script -> vagrant -> ansible -> docker


教育とトレーニング

⁃ よくある質問⁃ 「 Elixirでコードを書く為に、 Erlangの知識は必要ですか？」

⁃ 回答 ( 異論は認める )⁃ 設計時に OTPの知識が必要です⁃ 何かと Erlangのコードを読む機会はあります⁃ デバッグ、 etc

⁃ 完全に F/Wに乗れば機会は少ないかもですが、あったほうが圧倒的に「安心」です



⁃ 目的⁃ Elixirで「業務」ができるレベルまで、エンジニアのスキルを引き上げる

⁃ やったこと⁃ 読書会 / 輪読会⁃ ペアプロ⁃ PRレビュー

・独習 / 勉強会 / ハンズオン・業務と並行



⁃ 読んだ (読んでもらった )書籍⁃ 「プログラミング Elixir 」

Dave Thomas( 著 ), 笹田耕一・鳥井雪 ( 翻訳 ),オーム社 ,2016

⁃ 「すごい Erlang ゆかいに学ぼう ! 」Fred Hebert( 著 ), 山口能迪 ( 翻訳 ),オーム社 ,2014

⁃ 「プログラミング Erlang 」Joe Armstrong( 著 ), 柳原一矢 ( 翻訳 ),オーム社 ,2008


おまけ

Thank You!



⁃ 学ぶべき事項⁃ Elixir⁃ Erlang/OTP⁃ アクターモデル (プロセスの扱い )⁃ 並行プログラミング⁃ 関数型言語⁃ テストフレームワークの使い方

・ Haskellの入門書 !

・ Elixir本・Erlang本

・meckのドキュメント・テストライブラリのドキュメント


組織 /コミュニティ /MeetUp⁃ JapanElixirAssociation

⁃ ElixirConfJapanの主催・運営⁃ 2018年も Confを予定

⁃ tokyo.ex⁃ 東京近辺の Elixir/Erlang関連イベント , 隔月⁃ https://beam-lang.connpass.com/

⁃ Sapporo.beam⁃ 札幌近辺の Beam系言語meetup, 毎週⁃ http://sapporo-beam.github.io/⁃ Idobataでリモート参加可

https://beam-lang.connpass.com/

https://beam-lang.connpass.com/

http://sapporo-beam.github.io/

http://sapporo-beam.github.io/


組織 /コミュニティ /MeetUp⁃ Elixir関連イベント ( 参加者 20人以上 )

ElixirConfJapan


組織 /コミュニティ /MeetUp⁃ Elixir関連イベント ( 参加者 20人以上 ) tokyo.exとしては

今後ハンズオンに力を入れていきたい

ex) Erlang ハンズオン


組織 /コミュニティ /MeetUp⁃ 是非イベントへお越しください

⁃ 来年も ElixirConfJapanを予定しています

⁃ 東京近辺在住なら tokyo.ex へ⁃ 知見者が多いので相談出来る事も


まとめ

⁃ Elixirの導入に関する知見を共有しました

⁃ まずは素振りから始めましょう⁃ 「プログラミング Elixir 」は最適

⁃ OTPの理解は大切です⁃ プロセス構造を理解すると捗ります

elixir-conf-japan-2017-session-ohr486

Engineering