TREASURE DATA社主催のSRE勉強会に行ってきた
昨晩、こちらの勉強会にお邪魔してきました。
以下は発表概要と所感です。
※発表資料はまだ公開されていないものもあるようですが、捕捉したらなるべくこの記事にも載せます。
BUILDING RELIABLE SERVICES
TD社のSRE Chris Maxwellさん(@WrathOfChris)の発表。
Tokyo SRE Meetup - Building Reliable Services - A Journey from servers to services from Chris Maxwell
TDはかなり色々なサービスがあって、それぞれデプロイ方法や構成方法がバラバラでだいぶカオスな状況だったけど、最近スタンダードを作るようにしていて、段々よくなってきている、というような趣旨だった。
英語の発表だったけど、とてもきれいな発音で聴きとりやすかった。
prismatix SREチーム立ち上げからの1年間
クラスメソッドの望月さん(@Canelmo)の発表。
prismatixというのは、クラスメソッドさんの子会社で提供しているサービスで、ECとCRMを簡単に構築できるAPIプラットフォームらしい。
お客さん向けにそれぞれAWSアカウントを作って提供しているので、複数アカウントの管理・運用をいかに効率的にするかが肝、といった話があった。
特に興味深かったのは以下の点:
- CloudWatch Logsにはアラートに必要なログだけを入れ、全ログはS3に保存している。
- CloudWatch Logsに全ログを保存すると高くつく
- S3に保存していれば、バケットの参照を許可していれば一箇所からAthenaでクエリすることができる。
- 監視にDataDogを使っている。DataDogは複数AWSアカウントに対応していて便利。
あと、クレデンシャルの管理はどうしているのだろう？ と気になったので質問してみた。
これは「DSLとSSM Parameter Storeで管理していて、誰が実行しても同じ環境が構築できる」という話があったので。
回答としては、「クレデンシャル情報もSSM Parameter StoreのSecret Stringで保存している。誰がそこにアクセスできるかは別途(おそらくIAMで)管理している」というような内容だった。
スマートニュースの進化の歴史
スマートニュースの真幡さん(@mahata)の発表。
スマートニュースでのDevOpsやMicroservicesに対する取り組みについての話で、良い話だけでなくて悪い話もあって、わかりみがあった。
サービスが一定の規模を越えるとIaaSとエンタープライズ契約を結んだ方が良いというのは、個人的には頷ける話だった。
また、面白かったネタとしてSlackによるローカライズbotの話があった。
これはSlackの投稿に各国の国旗をリアクションで付けると、その投稿に対してスレッド返信の形で、その国の言語で翻訳した結果をbotが投稿するというものだ。
とても便利そうだと思った。
世界最大のレシピ動画サービス「クラシル」を支えるインフラ
delyの深尾さんの発表。
深尾さんは元イタリア料理人だそうだ。
氏がクラシルにjoinしてから、どのようにインフラの改善を行い、SRE的なプラクティスを実践しているのかを発表した。
なんでもやるわけじゃなくて、人員リソースを考慮してやる・やらないをはっきり決めているのがとても良いなと思った。
まとめ
各社のSREに関する取り組みを聞けて良い刺激を得られた。
Web系を中心に日本のテック業界にもSREのプラクティスが広まってきているように感じる。
TECH PLAYに行ったのは2回目だけど、相変わらずきれいで雰囲気の良い会場だった。
今回は軽食ビュッフェと飲み物が豊富に提供されて、飲食を楽しみながら聴講することができた。
主催してくださったTREASURE DATAさん、ありがとうございました！！
おまけ
以下は会場で取った雑なメモです。
ほとんど清書してないので、気が向いたら見てください。
Chris Maxwell @WrathOfChris
SRE
BUILDING RELIABLE SERVICES
- Why?
- Building Reliable Services
- cannot buy reliability
- tools
- daily workload
- 400,000+ queries / day
- 1 M+ events / sec
- 15+ Trillion Rows / day
- runtime convergence
- cookbooks ... Chef
- Our hero
- infra engineer & SRE
- increase velocity
- faster than weekly deployments
- more sites
- complex platform
- Service Delivery is hard
- measure reliability
- foundation is dirty work
- Wisdom from outsie
- simple first
- on experts and advice
- mentor returns
- chunks ... 7
- first changes
- standard deployment targets
- standard startup services
- Derek Coolison
- hard work ahead
- wrap up service
- autoscale group
- Presto
- Simple is Hard
- 3 sources of configuration truth
- Didn't have time for API
- 6 friends for the journey
- Autoscaling
- App Load Balancer
- EC2 Security Group
- Code Deploy
- Route 53
- IAM role
- More friends
- trust team
- Don't solve problems with software that should be solved with talking
- Mentor returns
- tools express process
- process should uplift the organization
- Service Tool
- 6 infra api w/ MVP tools
- Leverage immediate gain ... orchestration
- paying interest ... learning team
- 6 infra api w/ MVP tools
- Services First
- any engineer can
- release frontend/backend
- any engineer can
- Complexity ... enemy
- cut & paste and grow ...
- unclear boundaries
- Migrate
- simplifying complex
- many transitional changes
- precision replacement
- Process
- Legacy Process
- Transition
- Standard Services First
- With standards, exceptions are hard
- 新しいやり方でリリースできた！
- remaining services
- The way home
- Best Practices
- Standard services
- Best Practices
- Remaining services
- service improvements
- support config management
- strategy to improve
- heroes
- Yuu Yamashita
- Yuki Ito
- Kokubun
- Chris
prismatix SREチーム立ち上げからの1年
クラスメソッド望月
- @Canelmo
- prismatix SREチームリーダー
- AWS認定SA / DevOps Professional
- prismatixの紹介
- アーキテクチャー
- リリースと
- Developers.IO
- prismatix
- システム特性
- 技術スタック
- 全文検索したいデータをKinesisに流してElasticsearch Serviceに登録
- クライアントごとに個別の環境をセットアップ
- AWSアカウントも独立させる
- デメリット:
- 新規案件が増えるたび、環境も増える
- JOIN時のデプロイ方法
- 改善: 完全に再現可能なインフラにする
- シングルテナント
- セットアップ内容を完全に自動化
- 環境ごとの差異が発生しないように
- 何かあればrebuildできるという安心感
- インフラのテストにも使える
- デプロイの見直し
- これからやりたいこと
- インフラCI
- Elasticsearch index構築高速化
- 監視ツール
- 監視対象
- CloudWatchメトリクスとOSメトリクス
- ログ周り
- JOIN時
- EB => CloudWatch Logsに送信
- いくつかのログはOSに入らないと見えない
- 変更後
- ECS Cluster
- Log Driver -> fluentd
- S3にログ保存
- LBにログを飛ばす
- fluentd
- CloudWatch Logs
- 他 etc
- fluentd
- Log Driver -> fluentd
- ECS Cluster
- JOIN時
- CloudWatch Logs
- 割りとお高い
- 通知が必要なエラーを送る
- Athena
- 質問:
- credentialの管理
- Parameter Store
- 誰が操作できるかを別途管理
- Parameter Store
- cloudtrail logs
- 各アカウントごと
- Elasticsearchの性能劣化について
- つらいことはある
- K8s考えなかったのか？
- AWS使う前提だった
- credentialの管理
スマートニュースの進化の歴史
- @mahata
- Software Engineer
- ややインフラ寄り
- ニュース配信基盤担当
- SmartNews
- クーポンチャンネル
- オフィス風景
- ニュース配信基盤
- 監視
- Data Dog
- 配信
- Cloud Search
- 検索
- 収集
- 監視
- スマートニュース特有のチャレンジ
- 日米で開発拠点を分散させる難しさ
- 言語の壁
- 空気感（？）の違い
- 日米で開発拠点を分散させる難しさ
- 言語の壁
- 半年に1度は海外ワーク！スマニューならカンファレンスも
- インフラの構成管理
- 避けたいこと ... Dev vs. Ops
- インフラの構成管理
- Dev ... コードを書くことでインフラを設定
- Ops ... コードレビューでインフラを安定化。コードも書く
- => SRE
- ツール:
- Terraform
- Itamae + Fabric (+ カスタム Fabfile)
- IaaSとエンタープライズ契約
- Microservices
- 社内コミュニケーションHacks
- 読書会 ... SRE本
- Work Out Loud
- 人目につくところで開催する
- 資料も人目にふれるところに置く
- 参加者が増える
- お寿司
- 勉強会に予算を付ける
- これから解決すべき課題
- システム障害に強い体制づくり
- 適切なメトリクスの取得
- 適切なアラート設定
- システム障害対応あるある
- すごい人
- システム障害に強い体制づくり
- Q&A:
- Chaos Monkeyとか使ってる？
- 使わなくても色々起きてる
- Chaos Monkeyとか使ってる？
現場で使えるSite Reliability Engineering
Fukao Moto / dely
- ブンさん
- 元料理人
- クラシル
- 1分でレシピがわかる
- 2017年メディア露出多い
- 昨年末に1,000万ダウンロード
- 1人目のSRE
- Web / DBはシングル構成
- 監視未整備
- スケーラビリティ
- 可用性
- SPOFをなくす
- バックアップ
- 自動復旧
- モニタリング
- 監視メトリクス
- サチュレーション
- キャッシュ
- Memcached
- Nginx
- プロトコル
- 変更に強い設計:
- ログ収集基盤:
- fluentd + forrest
- 構成管理
- コード化 & DRY
- ログ収集基盤:
- SLO
- なぜSLOが重要か？
- 全アラートに対応？
- 信頼性をあげる作業には終わりがない
- 減点方式から目標達成方式に転換
- なぜSLOが重要か？
- どうやってSLOを決めるか
- ユーザ目線
- CloudWatch Metrics
- パーセンタイル値
- Infrastructure as Code
- DRY原則
- ツールやFWは任意
- タグで管理
- 論理名と物理名
- DevOps
- カナリアリリース
- ChatOps
- イベント対応
- Webのトップページを守ろう
- スマステ
- 予期せぬ数十万UU
- 新規ユーザ獲得
- 遅いページで全体が詰まる
- Nginx
- pathによってupstreamをグルーピング
- cache
- スマステ
- コミュニケーションロス
- イベント対応レベルを決める
- Webのトップページを守ろう
- ポストモーテムに書くこと
- タイムライン
- 良かったこと
- 悪かったこと
- 幸運だったこと
- 書かないこと
- 根本原因分析
- 再発防止策 => Issueに
- ※犯人探しはしない
- TODO管理
- SRE Principles
- 主体的に行動できるように
- 得意分野を活かす（生産性）
- Why, Whatを共有
- 3W, 1Hはあえて共有しない
- Whenは決めない。Whyがわかってれば優先順位はわかるはず
- 何をやらないかを定義 ★
- 3W, 1Hはあえて共有しない
- ミッション
- 意思決定に必要な指標を取得し、正確性を保証する
- SREミーティング
- 会議コストを最小化
- アジェンダを事前共有
- 週次/隔週/月次
- 金曜に実施 ... 週末に準備できる
- リスクマネジメント:
- 何もやってないとまずい
- 小さなコストで大きなリスク
- APOLLO Program
- 障害対応訓練
- まとめ
- 費用対効果を重視
- スケーラビリティの確保
- スコープ ... やらないことの選択
- WHYを共有
- Q&A
- 障害対応の再現方法
- 根本原因を調べないと再発防止できないのでは？
- 根本原因を調べることもIssueにする
吉祥寺.pm #13 で医療Webサービスの基盤技術について発表してきた
昨夜、吉祥寺.pmというテックイベントで発表してきました。
私の発表資料は下になります。
現職では、多様な医療Webサービスを展開しているわけですが、それらのシステムの構成要素であったり、裏側のインフラ事情であったり、開発で利用しているツールなどを幅広く紹介した形です。
もう少し自分自身の業務内容に近づけた方が良かっただろうか、という思いもありましたが、懇親会などで「プロダクション環境で動作しているシステムの事例として参考になった」というような感想も頂き、これはこれで良かったかなと思いました。
私以外の発表で行くと、エンジニアの健康の話や、プログラミングの設計、Webアーキテクチャーを実装して学んだ話と、吉祥寺.pmらしい多彩な内容だったと思います。
もちろん、Perlの話もありました（笑）
発表やLTの資料は、私のものも含めて上述のConnpassのページにUpされるようです。
懇親会にも参加しました。
「オフラインでお会いするのは初めてですね」という方も何名かいらっしゃいました。色々と面白い話が聞けて良かったです。
このような機会を頂き、ありがとうございました。
次回の吉祥寺.pmは5月に開催予定とのこと。
都合がつく限りなるべく参加したいなと思います。
余談
前回、吉祥寺.pmで発表したのは約2年半前のことだったようです。
当時とはハンドルネームが変わったため、呼び方で戸惑わせてしまったようです。*1
*1:「きいあむさんと呼んでしまう」と言われました。すいません。。（汗）
Redash Meetup #0に参加した
RedashはOSSのハンディなBIツールとして、ちょくちょく名前を聞いて気になっていましたが、あいにくこれまで触ってみる機会がありませんでした。
そんな折にこちらのハンズオンを見かけたので、行ってみることにしました。
ハンズオンは、@kakakakakkuさんがGitHubに公開して下さっている下の資料に基いて実施しました。
丁寧に作られているので、今回のMeetupに参加していない人でも、こちらに沿って作業すると一通り内容が掴めるだろうと思います。
ハンズオン実施項目
上の資料の目次相当のものを書き下します:
- Redashをローカルマシン上でセットアップ by Docker Compose
- データソース設定 : MySQL
- クエリ作成
- クエリ結果をグラフ化(Visualize)
- Counter
- 円グラフ
- 棒グラフ
- ダッシュボードの作成
- グルーピングについて
- パラメータ付きクエリの作成
- フィルタ機能
- クエリスニペット
- プレースホルダの設定
- クエリ結果にHTML埋め込み(色を付ける)
- クエリ結果にURLを含める / リンク集の作成
- クエリ結果をダウンロードする
- クエリをフォークする
- Slackアラートを設定する
割りとサクサク進んで、やや時間が余ったので、追加で以下のようなこともやりました:
- 時系列グラフの作成
- Redash内部のPostgreSQLをデータソースに追加してクエリ作成
- 一般ユーザの追加
- 管理画面へのアクセス
Q&A
いくつか運用に関して気になったことなどを講師の方々に聞いてみました。
- Redashサーバをどうやって立てていますか？
- クラウドでall-in-oneのインスタンスを立てている。 https://redash.io/help-onpremise/setup/setting-up-redash-instance.html にAWS, GCEで使えるイメージが公開されている。
- PostgreSQLのデータをバックアップしている。
- ハードに使っている人だと、PostgreSQLのデータをRDSに移したりするケースもある
- 権限管理どうしてますか？
- Redashのデータソースに対する権限設定はFull AccessかRead Onlyしかない
- Read Onlyにするとクエリ実行すらできない => あまり実用的ではなさそう
- データソースにするDBMS側で権限設定している。
- CLIとか駆使すればデータソースに対して細かい権限設定もできるっぽい。誰かがアドベントカレンダーに書くらしい
- Redashのデータソースに対する権限設定はFull AccessかRead Onlyしかない
その他こぼれ話
- トラブル事例:
- ディスク容量の逼迫 ... 大きな結果セットのクエリが投げられ、Redash内部のPostgreSQL側にキャッシュされてディスク容量が逼迫した
- 対策として、キャッシュのパージ設定を調整することができる
- ディスク容量の逼迫 ... 大きな結果セットのクエリが投げられ、Redash内部のPostgreSQL側にキャッシュされてディスク容量が逼迫した
- Undocumentedな機能が色々ある
- JSONを返すURLとか、シェルコマンドとかもデータソースに使えるとか
感想
BIツールをあまりハードに使い込んだことはないのですが、Redashは便利な機能が色々揃っていて、セットアップも簡単で良いツールだなと思いました。
権限管理など、大規模に使うには少しつらそうな感もありますが、小〜中規模では問題ないのではないでしょうか。
終わりに
次回開催予定について尋ねてみたところ、1〜2月ごろに#1を行いたいと仰ってました。
また、今回のハンズオン内容の再演も春頃（？）に行われるようです。
講師を務めてくださった@ariarijpさん、@kakakakakkuさん、ありがとうございました！
DockerizeしたCLIを使うことについて
昨今、Dockerを使って開発することが当たり前になっている、という人も増えているのではないか。
その場合、開発に必要なツールがDockerに対応していると楽だ。
それはサーバ製品に限らない。
人によっては、 mysql コマンドやAWS CLIといったクライアントツールもDockerizeされたコンテナイメージを利用しているということもあるだろう。
…で、それは多少のトレードオフはあるものの、概ね便利と云って良さそうだ。
Pros
- インストールが楽。docker runしたらイメージが落ちて来るので、インストールのために何かする意識がほぼ必要ない。
- ツールの依存物がコンテナに閉じるので、ローカル環境を汚さないで済む。
- 環境差異にまつわるトラブルを減らせる。「オレの環境では動くのに」問題を減らせる。
Cons
- Dockerに関するトラブルがあったときに、仕組みをわかってないとシューティングが難しそう。
- CLIの起動にオーバーヘッドがかかり、フットプリントが大きくなる（と思う）。気にならないレベルなら良いのでは。
- ストレージを消費しやすい。
1つ目については、CLIにちゃんと適切な環境変数なりを渡してあげないといけないとか、作業ディレクトリを用意しないといけないとか、そういう注意点はありそう。
2つ目、3つ目については、Alpine LinuxなどミニマルなOSをベースイメージとすることで、ある程度抑えられる。
最近、自分でも勉強がてらAWS CLI*1やAnsible*2をDockerizeしてみたけど、まだちゃんと使ってみてないので、特に上の1つ目の点にはハマりそうだなと思っている。
参考
『サイトリライアビリティエンジニアリング』を通読した
8月に邦訳本が発行されたGoogleの『SRE サイトリライアビリティエンジニアリング』を通読しました。
…といっても、今のところいくつかの章はスキップしてしまっているのですが、凡その全容は掴めたかな、というところです。
10月の終わり頃から読み始めましたが、すごく分厚くて(500p超)読むのに時間が掛かりました。
各章は10〜20ページぐらいの記事のような形になっているので、空き時間に章単位で読み進めていくとよさそうです。
全体的な感想
前職でサーバインフラに関わる仕事をしていたこともあり、わかりみの深い話が多かったです。
うんうんと頷くこともあれば、Googleのシステムに感動したり、目から鱗が落ちることも度々ありました。
本書は、サイトの信頼性を維持し、かつ、サービスの変更の速度を落とさないためにGoogleが実践している様々な取り組みや、Googleのシステム/アーキテクチャを解説しています。
技術的な内容はGoogleのシステム・インフラを前提としているものの、大規模システムに留まらない有益な示唆に富んでいると思います。
そういった技術的な各論も非常に面白いのですが、よりメタな概念として、本書から得られる学びの中で、以下の3つはキーポイントだと云えるでしょう:
- SLOを定めること（3, 4章)
- トイルの撲滅(5章)
- ポストモーテムを書くこと(15章)
SLOについて
SLOについては、「クライアントのバックエンドサービスに対する過剰な信頼と依存を避けるために、わざとバックエンドサービスを計画的に停止している」(4章のコラム「Chubbyのグローバルな計画的サービスの停止」を参照)というのは、衝撃的な内容でした。
話としては理解できたものの、プロダクション環境で動いているバックエンドサービスを、そういう目的でわざと止めることが自分にできるかは未知数です。
ちょうどSRE本で読んだんだけど、システムのサービスレベル目標を過剰に達成すると、ユーザはそれがシステムで保証された品質だって思って過剰に依存しちゃうんだって。
— progrhyme (@progrhyme) 2017年10月29日
ポストモーテムについて
この語は私にとって初見でした。
本書においては、「インシデント（なんらかのトラブルやサービス障害）の経緯を記録し、振り返りやその後の改善施策、教訓とともにまとめるドキュメント」と云えましょうか。
付録Dにポストモーテムの例も載っています。
15章では、Google内でのポストモーテムに対する考え方や、ポストモーテムを活用するいくつかの取り組みが紹介されています。
ポストモーテムを広い範囲に共有し、誰もがそこから学べるようにするというやり方は素晴らしいなと思いました。
むすびに
本書の中では、「こんな風にできたらいいな」と理想論に感じるような内容も無いではなかったです。
とはいえ、すぐにできることもありそうだし、目標を定める上でのベンチマークとして参考にすることもできそうだと思いました。
例えば、「SLOを定めましょう」「SLOを達成できているか計測しましょう」「これはトイルなので、工数削減のために機械化します」「障害をチケットに書いて後で振り返れるようにしましょう」とかは、当たり前のこととしてやっていけばいいなと思いました。
冒頭に書いたように、まだいくつか未読の章があるので、そちらも追って読んでしまおうと思います。
GoogleサイトでWiki用のシンプルなテンプレートを作った
こんにちは、Googleサイト愛用者の id:progrhyme です。
紆余曲折を経て、はてなブログに帰って来ました！*1
はじめに
さて、ブログ記事にするまでもない雑なメモをGoogleサイトに書くことにしたのは、およそ1年前のことでした。*2
それ以前にもGoogleサイトでサイトを作ったことは何度かありましたが、これをきっかけにGoogleサイトを頻繁に更新するようになりました。
その後も、非公開のサイトや、最近アカウントを作り直したこともあって、いくつかGoogleサイトを作る機会がありました。
…で、Googleサイトを作るときに毎回テーマを選んで、フォントサイズなどスタイルを調整していましたが、それが面倒になったので、今回テンプレート化しておくことにしました。
なお、コードは1行も書いていません。
作成したテンプレート
https://sites.google.com/site/progrhymewikitemplate/
こちら↑になります。
テンプレートにも書いていますが、補足も兼ねて何をやったか書いておきます。
- ベースにした基本テーマは「シンプル」というもの。
- フォントサイズを全体的に一段階ずつ大きめに。
- デフォルトは地の文が10pxで、少々見づらく感じます。
- 「目次付き」テンプレートを用意 ... 右サイドバーにページ目次を表示
- 少し見た目を調整
- CC0ライセンスの幾何模様っぽい背景画像を設置
- タイトルヘッダを黒に
まとめると、大したことはしてないのですが、個人的にはこれで十分です。
次からWikiを作るときは、これを使うつもりです。
終わりに
Markdown Hereというブラウザ拡張機能を使うと、GoogleサイトのページをMarkdownで作成できるようになります。
個人的には、技術メモなどをGoogleサイトに書くのはかなりオススメです。
主には自分用に作ったテンプレートですが、よさげに見えたならば、自由にご利用下さい。
もし使ってみて、「こんな機能もつけてほしい」などの要望がありましたら、この記事のコメントやSNSなどでお知らせ頂ければ、対応するかもしれません。
Googleサイトでふだん使っていない機能も多いので、自分では思いつかないようなニーズもありそうです。
それでは、Enjoy!
関連記事（過去ブログより）
脚注
Workflow Engines Meetup #1 に行ってきた
初めまして、というべきでしょうか。
@progrhymeとしての初の技術ブログ投稿になります。*1
今日は田町で開催されたWorkflow Engines Meetup #1に参加してきました。
目次
発表タイトル・資料一覧
※まだ全部上がってないので、捕捉したら更新します。
(1) Digdagの特徴とQuick Start / @frsyuki
(2) Jenkins 2.0 Pipeline & Blue Ocean / @hico_horiuchi
(3) Luigiを使っている話 / @bwtakacy
(4) Azkaban in my use case / @wyukawa
(5) Airflowの紹介 / @sekikn39
聴講メモ
Digdagの特徴とQuick Start @frsyuki
今回はアメリカ西海岸からのリモート発表。
- Workflow Engine とは
- あらゆる作業の自動化
- 要求される機能
- 依存関係の定義
- 過去分の一括やり直し
- エラー処理
- レジューム
- 状態監視
- 実行時間長いときに通知
- 可視化
- 開発支援
- WFのバージョン管理
- 世にあるWF Products
- OSS, 商用ともたくさんある
- WF定義方法による分類
- digdag
- タスクのグループ化
- 1つに見せかける
- グループ化されたタスク内で、子タスクを実行
- 何がよいか？
- WFグラフが単純になる
- デモ
+でタスクx>オペレータtd>… TDecho>,sh>, etc.
- 失敗
- taskが1個失敗
- state が保存される => resumeできた
- taskが1個失敗
- TDとの連携
- サーバでWF管理ができる
- 管理画面付き
- digdag push
- WF管理
- job管理
- ログ
- 色んなオペレータ
s3_wait>,redshift>- s3にファイルができたらredshiftにコピー、とか
emr>,pg>,mail>- pluginで追加できる
- Loops & Parameters
- for_each operator
loop>- operator一覧: http://docs.digdag.io/operators.html
- GCPもある
- ドキュメントのリンク
- AWS re:Invent … 1h 丁寧な解説
- Qiitaに有益な日本語情報:
- Q/A
Jenkins 2.0 Pipeline & Blue Ocean @hico_horiuchi
- 自己紹介
- NTT Communications
- ベアメタルクラウドの開発
- JenkinsとAnsibleによるデプロイの自動化
- Jenkins
- 2011年に Hudsonからフォーク
- ジョブ: shell script, groovy
- 元々の目的: 開発ルーチンの自動化
- Jenkinsおじさんの必要性
- ジョブ生成が属人化する
- 依存関係が複雑化
- plugin何が入っているか不明
- バージョンアップすると動かない
- Pipeline と Blue Ocean
- Pipeline Plugin
- DSLで定義できる
- 条件分岐、例外処理、並列実行
- Jenkinsfile
- branchごとに自動でジョブを作ってくれる
- Pipeline Syntax
- stage: ビルド、テスト、ワークフローの段階
- step: 具体的な処理
- 条件分岐と例外処理
- master branch だったらデプロイ
- Pipeline Plugin
- Blue Ocean Plugin
- UXをおしゃれに
- Pipeline の手順や状態を可視化
- ダッシュボード
- まだβ。活発に機能追加されている
- Design Language で統一性のある UI
- 同じUIでプラグイン作れる
- React.js 使ってる
- デモ画面
- WF見やすい
- デモ
- 環境
- ansible で docker コンテナ起動
- Pipeline でデプロイ WF を実装
- docker インストール
- リトライ
- Pipeline エディタ
- WFをいじれる
- 実行させるJenkinsのエージェントとか選べる
- shell script も書ける
- Jenkinsfileに吐き出せる
- WFをいじれる
- 環境
- Jenkinsの使いどころ
- テスト
- デプロイ
- 死活監視・外形監視とアラートの通知
- Jenkins 2.0に移行したい
- Multijob => Pipeline
- Job Builder => Jenkinsfile
- テンプレート展開の嵐
- Q/A
- Pipelineはresumeできる？ => できない。全部やり直しになる、と。
- Pipeline使うときBlue Ocean必須？
- 必須ではないが、使わないとUIはだいぶ残念な感じになる。
ちなみにJenkinsのStage再実行はここら辺で議論されてます https://t.co/VR7LKLufvk #wfemeetup
— ladicle (@Ladicle) 2017年3月9日
Luigiを使っている話 @bwtakacy
- 自己紹介
- 前職: SIer
- 青いゾウや黄色いゾウと戯れていた
- 前職: SIer
- データ分析基盤でのLUIGI
- リクルートマーケティングパートナーズ
- ゼクシィ
- 赤すぐ
- ★スタディサプリ … 小・中、高校生向けに動画提供
- 学習支援サービス
- 月額980円〜
- スタディサプリ・システム構成
- LUIGI
- embulk … 50+ のテーブルを連携
- Hive / Presto によるデータ集約・集計
- 30+ の Hiveクエリ
- Jenkins で LUIGI をキック
- TD Workflow (Digdag) で 10+ の Prestoクエリ
- LUIGIの基礎
- LUIGIの範囲じゃない
- リアルタイム処理、長期間継続実行する処理
- 分散実行はサポートしてない
- 処理のスケジュール起動やトリガ起動はできない
- スケーラビリティは追求してない
- 用語
- task
- target
- taskの正常終了を示す情報
- parameter
- 簡単な例
- examples/foo.py
- runメソッド … taskにさせる処理
- reuiqres … 前提にしているタスク
- examples/foo.py
- スタディサプリでの使用例
- TDへのクエリ発行はTDがluigi_tdモジュールを用意しているのでそれを使っている
- インストール
pip install luigi- WF実行
--local-scheduler- コマンド実行ごとにスケジューラが起動
- デモ
luigi --module foo examples.Foo --workers 3--workers並列数
- 困ったこととか
- taskの実行時間が知りたい
- PROCESSING_TIMEイベント
- ビルトイン・イベントとそれに対するコールバックを登録できる仕組み
- FAILUREイベント
- PROCESSINGイベント
- mixin作ってやってる
- PROCESSING_TIMEイベント
- 並列実行とコマンド戻り値
- デフォルトでは失敗しても戻り値 0
- retcode で設定できる
- LUIGI.CFG
- luigiコマンド実行時に読み込まれる
- RETCODEをバイパスしたWFができてしまう
- スクリプト内に
if __name__ == '__main__'とかのブロックでluigi.run()すると駄目
- スクリプト内に
- 並列実行すると戻り値がおかしくなる
- taskの実行時間が知りたい
- まとめ
- シンプルなWFを記述するには重い
- digdagに移行中
- 管理画面は大したことない
Azkaban in my use case @wyukawa
- Azkaban
- 構成
- mysql
- web server
- executor server
- シンプルなジョブ管理
- 依存関係
- リトライ
- Scheduling
- Web UI
- SPOF
- Log
- 12週間は表示される
- カレンダー
- 祝日の登録できない
- メール通知のみ
- 最近 HTTP Job Callback できた
- No binary
- ソースを自分でビルドしないといけない
- not so active
- ML 事実上機能してない
Azkabanはおっさんにやさしい（モダンじゃない）Javaで書かれており、ソースを自前でビルドする必要があり、開発は週に1回コミットがある程度で、MLは事実上機能していない。 #wfemeetup
— progrhyme (@progrhyme) 2017年3月9日
- Job File
- Javaのプロパティ形式
- 用語
- project
- job
- Scheduling
- Failure Options
- # difference when ccc failed
- Finish Current Running
- Cancel All
- Finish All Possible
- 依存関係ないジョブは継続実行する
- ★これがデフォルトで有るべきだが、そうなってないので全部指定している
- Re-run when failed
- 失敗したやつだけ再実行は簡単
- concurrent execution options
- skip execution … 多重同時実行しない
- run concurrently … する
- pipeline … 使ってないのでよくわからない
- Q/A
- Use case
- python batch example
- Job management overview
- git push
- git pull generate job file
- Jenkins - upload job
- git push
- これまで
- 120 のflow作った
- だいたいdailyバッチ
- azkaban in batch server
- backfill / 過去分のやり直し
- azkaban自身にこの機能はないが、工夫してやっている:
- azkaban flow を template 化して
- from to の日付を渡して実行
- azkaban自身にこの機能はないが、工夫してやっている:
- SLA 使ってないが使うかもしれないので PR している
- 120 のflow作った
- 所感
- シンプル
- 使いやすい
- Web UI 便利
- API 便利
- 別のものに置き換える理由はない
- ozaさん(？)からのコメント:
「開発を活発にするには、今まで実行したジョブの数をMLに送るといい。開発者がテンション上げてくれる可能性がある」 #wfemeetup
— progrhyme (@progrhyme) 2017年3月9日
Airflowの紹介 @sekikn39
- 自己紹介
- Airflow に興味を持った背景
- 概要・機能紹介
- デモ
- Web UI
- DAG 閲覧
- job 実行
- fail
- executor 指定できる
- Web UI
- 要望
- 不足機能
- HA構成のサポート
- DAGの登録・更新・削除をWeb UIから実施したい
- TZ UTC以外のサポート
- Web UI から WF の任意の場所でジョブを再開等
- 不足機能
- Airflow Meetup Tokyo?
- PMC chairに会ったら、東京でもやったらと提案をもらった。
雑感
- Digdag段々機能が充実してきているのを感じた。
- Jenkins, Blue Oceanはまだβだが、Pipeline Pluginと組み合わせて使いたい。
- Luigiは、つらみを感じた。
- Airflow, UIきれい。
終わりに
第2回も有るっぽいので、楽しみ。 @sonots 氏の Trigrav や @joker 氏の Rukawa の話が聞けるかも。
*1:最近ハンドルを変えました。前は id:key_amb でした。以前の技術ブログは、weblog of key_amb
