3月6日に行われた、SRE-SET Automation Night #2にブログ枠として参加してきました。
会場は株式会社メルカリのセミナールームです。Google Cloud Platformハンズオン のときも六本木ヒルズ森タワーに訪れたのですが、相変わらずビルセキュリティが厳しいし構造がよくわかっておりません。
登壇場です。シンプルでクールですね。
飲み物は発表中も自由に飲めます。アルコール類だけはなくてノンアルコールやソフトドリンクもあるので私のようなお酒の弱い人には嬉しいですね。
オシャレな食事も用意されています。この後の懇親会でつまみます。意外とお腹が膨れます。
- レポート
- 懇親会
- 最後に
レポート
Ansible 2.5 におけるネットワークモジュールのトピック
www.slideshare.net
株式会社エーピーコミュニケーションズ
横地 晃さん (@akira6592) さん (金魚のアイコンが特徴です)
Ansibleとネットワーク対応
Ansibleの特徴でAgentlessが最も大きい。 SSHやNETCONFで接続して、状態取得や設定変更を行う。 ネットワーク機器(Ciscoなど)も対応している
Ansible 2.5
正式版は3月中予定
ドキュメントの整備
ドキュメントに「Ansible for Network Automation」が増えた。
ベストプラクティス
ディレクトリ構造
3. 対応プラットフォームの追加
特徴的なのが - Cisco NSO - Fortinet Fortinamanager
4. ネットワークモジュール
今まではlocalがメインだった - network_cli - netconf
localでも良いが新しいネットワークモジュールでないと2.5から使えない機能もあるのでこちらにしたほうがよい。
5. エラー
エラーがわかりやすくなった。 今まではunable to open shellしかでなかった URLも消えてかなり見やすくなった
6. 特権モード移行方法の追加
2.4まではネットワークモジュール固有の書き方だった。
2.5からはansible_becomeが使えるようになり、ネットワークモジュール固有の癖が軽減された
7. Persistent connectionsの仕様変更
コネクションの切断タイミングが変わった
2.4まではコネクションが残って次も使いまわす。 2.5からはPlaybook終了後に切断される
まとめ
ネットワーク向けのドキュメントが拡充された。今までもあったが散乱していたのがまとまってわかりやすくなった。 対応プラットフォームが増えた ログがわかりやすくなった。
感想
恥ずかしながら実はAnsibleにはほとんど触ったことがなく、専らChefがメインでしたが、Ansibleでネットワーク機器にも使えるのは知りませんでした。
エージェントレスなのはとても良いですし、2.5になったことでプロダクトとして成熟してきた印象を受けました。最近の主流になってきているのでこれを機に本格的に使ってみたいと思います。
AWS Lambdaで作る GitHub bot
株式会社メルカリ
佐々木 健一 (@siroken3) さん
SREをされています。
GitHub bot
- 造語
- botは人間っぽいもの
- Pull Requestへのコメントで何かをさせる
- レビュー機能(Request_changes)
今回は echo botを紹介
- repeat xxxx で打った内容をそのまま返してくれる
アーキテクチャ
- GitHubから AWS SNSに発火、AWS Lambdaが実行され、GitHub APIを叩く
- GitHubのトークンをKMSで暗号化
- Apexが生成したIAMロールが使えるように設定する
開発環境
- Node.js v6.10.3
- octocat
- デプロイツールはApex
- GitHubのトークン
- Personal access tokens
- 権限はrepo
サンプルリポジトリ
https://github.com/siroken3/SreSetAutomationNightVol2
GitHubの発行イベント
- デフォルトの発行イベントでは使えないので、
issume_commentを追加する。
注意点、所感・落穂拾い
- Bodyのmatchを気をつけないと無限ループになり無限実行される
- GitHub APIのドキュメントをしっかり読んでおく
感想
自動化といえばbotですよね！(偏見)
AWS Lambdaを使うことでサーバの面倒を見ることなくBotを作れるのはいいですよね。真似したくなる事例を紹介していただきました。
運用の負担を減らすログ送信システムの設計
www.slideshare.net
株式会社Aiming
鴛海太一さん
プログラマ兼データサイエンティストをされています。
所属チーム
- Monolith(モノリス)
- 複数のゲームタイトルを横断してデータ分析するチーム
- 各ゲームのログをBigQueryに送信する機構の開発、運用
以前のログ送信機構
- 各ゲームサーバからFluentdでBigQueryにログを送っていた
- スキーマ変更されると分析ができないことがあった
現在
Cloud Storageにログを蓄積 Cloud Pub/Subに送る Pub/SubからBigQueryに直接送れないのでloloというログ送信機構を開発した
lolo
- Pub/Subの重複を排除してくれる
- at least once(最低でも1回以上送る)なので重複の可能性がある
- logの語源からとっている
- log = 丸太
- 丸太を運ぶ山林の道をイメージ = loggig load => lolo
- ETLの役割を果たしている
- Extract(データの抽出) / Transform(加工) / Load(読込)
アーキテクチャ
- Extract Transformer, Loaderに分かれている
- それぞれ別プロセス
- 毎時cronで実行される
自動化の問題
手動で対応しなければならないケースがある
スキーマが違うログが遅れられてきたときはコミュニケーションをとる
例外の種別を明確にする - warn - 想定されているかつ自動対応可能 - error - 想定されているが手動対応が必要 - fatal - 想定されていないかつ手動対応が必要
- べき等になっているので何回でも実行可能
- 他のプロセスに影響しない
- 心理的負荷を減らす
感想
送られてくるログの種類やスキーマが異なるという問題点に対してできるだけ運用負荷や心理的負荷を減らすための工夫を中心に紹介されていました。
とくに例外の種別を明確に定義されているのは素晴らしいですね。自動化の設計をする際に真似しようと思います。
自動化をするにあたり、運用者のこういった負荷を減らすことは良いこと(むしろ必須!?)なので、とても参考になりました。
公開スライドにはないのですが、発表中に画面下にでてくるキャラクター(時間経過とともに移動している)のがとても気になりましたw
退屈なブラウザ作業をpuppeteerにやらせたいお話
株式会社メルカリ
根本 征 (GitHub: tadashi0713)さん
QAチームでモバイル端末のCI自動化やノンプログラマー向け作業の自動化について取り組まれています。
- ブラウザ作業を自動化したい
- Selenium Webdriver
- 複数ブラウザでやらなくてもいい
- 環境構築が面倒
- スクリプトを組むのも面倒
- GoogleChrome/puppeteer
- Node.jsからChromeを簡単に扱える
- Browserless Debugger
- デバッグに便利
- セレクタを取ってこれたり便利
- index.jsとpackage.jsonがダウンロードできるのでnpm installするだけで済む
感想
私が属している会社では勤怠とやったタスクの工数(時間)の入力をブラウザでポチポチする作業が毎月発生するのですが、いい加減自動化したいなと思っていたのでpuppeteerを試してみたくなりました。
Seleniumだとちょっと重いしガッツリ使いこなしたいとは思わないので簡単にできそうであれば試してみたいですね。
世界のカンファレンスから～SeleniumCamp 2018～
@mkwrd さん
3月2〜3日にウクライナの首都(キエフ)で開催されたSeleniumCamp 2018に参加された様子を紹介されていました。 メモしようとしたのですが、内容の多さと面白さに圧倒されてメモし忘れてしまいましたw
場所がウクライナということもあり、日本人は @mkwrd さん一人だけだったとのことです。また、地理的にも英語のセッションが少なくてロシア語セッション多めだったのが残念だったみたいです。
日本人一人で完全アウェイなのにいろんな人と一緒に写真を撮ったり英語で話しかけていたので、そういったイケイケな姿勢は見習いたいです(私は臆病なので)。
メルカリの自動化への取り組み
www.slideshare.net
株式会社メルカリ
k-oguma さん
元ゲーム会社のインフラエンジニア、今はSREをされています。
SREの業務の流れ一例
- 出勤と退勤はWi-Fiに接続/切断時に自動で打刻される
- タスク管理はslackでJIRAに自動的にTodoを追加
- VPNアカウントを作るのもSlackでできる
- SSHユーザ
- 専用のGitHubリポジトリにPRがマージされるとCIが実行されSSHユーザが作成される
BPD合宿
BPD = Be Professional Day
- 自分たちがつくりたいものを作る時間
- テーマは自動化
- 新しいことに挑戦できる
自動化するときに考えておきたいこと、守りたいこと
- 最低限のDocを書く
- 2度以上やるなら自動化するけど3回目もあるのか
感想
自動化で時間を空けるには、まず自動化するための時間を取らなくてはならないですよね。できるだけ手作業をなくして自動化するために、合宿を開くのは羨ましいです。Wi-Fiの接続/切断で出勤と退勤の打刻が自動でされるのはいいんですね。私が所属している会社では･･･(二度目なので省略)。
botでアカウント作成やタスク管理を簡単に実行できる例は参考にさせていただきます。
node-core-utils
https://abouthiroppy.github.io/slides/node-core-utils/
株式会社ドワンゴ フロントエンド(JS)エンジニア
hiroppyさん
- Jenkinsで多くのプラットフォームに対してテストを回している
- node-core-utils
- Node.jsのコアな部分。つい最近出た
- コミットルール
- Masterブランチにマージする場合は24時間待つ(休日は48時間)
- 世界中にコミッターがいるため
- コミットルールの判別は自動化されている
自動回帰テストフローとGitHub Apps
@Quramy さん
フロントエンドエンジニア
テストやビルド周りの環境構築もされているとのこと。
GitHub Appsとは
- GitHubと連携するアプリケーションの形態
- GitHubのAPI実行によるリポジトリ
- Webhooks: リポジトリに起きたイベントに反応
- OAuth Apps
- GitHubのアカウントに紐づく
- GitHub Apps
- GitHubのリポジトリに紐づく
- 特定のアカウントに依存しないため、チームで開発する場合に向いている
求めていたもの
- 回帰テスト
- スクリーンショットを取って前回のと比較する。問題なければ最新のスクリーンショットに反映する
- 差分発生したものだけをチェックしたい
- 差分が発生した場合は一旦PRのCommitステータスをNGにする。レビューしてOKであればCommitステータスをOKに変更する
感想
GitHub Appsは初めて聞きました。GitHubのPersonalトークンだと発行した人に依存するのでチーム開発するには向いていないですね。
自動化(スクリーンショットの取得、前回との差分検知)と手動(前回との差分をレビュー)を分けてCIフローに組み込まれている例を紹介いただきました。
懇親会
発表を聞いた後は懇親会でワイワイしました。
オシャレな軽食はとても美味しかったです。
最後に
自動化の取り組みについて多くの事例を聞けて参考になりました。
弊部署では私ふくめて二人しかインフラ担当がいないのでいかに自動化をしていくかがテーマになります。最近は自動化するための時間さえも取れていないのですが、BPD合宿を参考に1日だけでも自動化するための時間を取るように工夫したいと思います。
タイトルがSRE SETなので、インフラ関係者が多いと思ったのですが、フロントエンドエンジニアが多いことが意外でした。
