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)
⁃ after
cache(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

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

⁃ 機能開発・テスト
⁃ TDDで開発
⁃ Red-Green-Refactor
⁃ 並行化の列を加えたマトリクス
⁃ 逐次処理・並行処理
⁃ Elixirは並行処理を簡単に書けるが、逐
次処理はもっと簡単に書ける（書いてし
まう）

⁃ TDD黄金の回転
きれ
い
汚い
動かな
い
動く
Red
Green
Refacto
r

⁃ TDD黄金の回転(並行版)
きれ
い
汚い
動かな
い
動く並行に動
く
Red
Green
Refacto
r
Concurrenize

⁃ 監視
⁃ Supervisorがワーカーを再起動するので通
常の死活監視ではサービスの瞬死を完全に
検知できない
⁃ 1分に1回のHeartBeatだとタイミングによってはスル
ー
⁃ →見かけ上は正常なので異常を検知できない
⁃ イベント単位での通知、KPI値の異常値に
よる検知
⁃ Sentry
⁃ https://github.com/getsentry/sentry-elixir
⁃ プロセスのcrash時に通知
⁃ →通知先(のsentry)へのDDoSになりかねない
⁃ re:dash
⁃ aleart機能

⁃ バージョンアップの頻度
2014/9/10 2017/3/14
v1.0
R17
v1.4
R19
v1.2
R18
2016/1/1
2014/9/10
v1.0
2015/9/25
v1.1 2016/1/1
v1.2
2016/6/21
v1.3
2017/1/5
v1.4
2014/9/10
R17.1
2015/6/24
R18
2016/6/21
R19
2017/4/1
v1.4.2
2017/4/1
R19.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でリモート参加可

⁃ Elixir関連イベント(参加者20人以上)
ElixirConfJapa
n

⁃ Elixir関連イベント(参加者20人以上)
tokyo.exとしては
今後ハンズオンに
力を入れていきたい
ex) Erlangハンズオン

⁃ 是非イベントへお越しください
⁃ 来年もElixirConfJapanを予定しています
⁃ 東京近辺在住ならtokyo.exへ
⁃ 知見者が多いので相談出来る事も

まとめ
⁃ Elixirの導入に関する知見を共有しまし
た
⁃ まずは素振りから始めましょう
⁃ 「プログラミングElixir」は最適
⁃ OTPの理解は大切です
⁃ プロセス構造を理解すると捗ります

Elixir-Conf-Japan-2017-session-ohr486

More Related Content

What's hot

Viewers also liked

Similar to Elixir-Conf-Japan-2017-session-ohr486

More from Tsunenori Oohara

Elixir-Conf-Japan-2017-session-ohr486