Forem: okash1n

｢最新DevOps事例勉強会｣に行ってきました

okash1n — Fri, 21 Sep 2018 16:15:08 +0000

元記事の方がスライドがembedされて見やすいです
https://okash1n.tech/2018/09/25/jddstudy-3-devops/

JDDさんが主催されたJDDStudy #3 最新DevOps事例勉強会！スタートアップとグロースフェーズそれぞれの開発チームが取り組むDevOpsの今。に行ってきたのでレポ

概要

プロダクトのスタートアップでリーンに立ち上げるタイミング、マーケットフィットを経てグロースさせるタイミング、それぞれのフェーズで開発体制や運用体制、運用手法は異なってきます。
なぜそのDevOpsになったのか？　　
DevOpsにこだわりをもつ3社をお招きして、ツール選定や意思決定の背景から、実際に活用してみた感想までをお伺いしていきます。開発をより効率的に！と考えている方、最新DevOps事例を聞きながら、一緒にディスカッションをしていきましょう！

DevOps on Merpay Microservices - 株式会社メルペイ高木潤一郎さん

Follow @tjun

スライド

20180920 DevOps on Merpay Microservices - Speaker Deck

SREってなんだっけ??

メルペイのアーキテクチャ

殆どはGoで書かれている
- Go microservice templateのようなコードがある
gRPCでやりとり

Merpay API Gateway

メルペイ側も改善する
CI/CD CircleCI -> Container Registry -> Spinnakerで自動デプロイ

運用の仕組みの共通化

Microservicesでは各サービスのチームがOwnerとなって運用をすすめていく｡技術選定も自由｡
とはいえ､SREや他のチームのメンバーがサポートするためには共通化が必要
運用の仕組みの共通化がDevOpsでは大事
- 皆が好きに仕組み作るといざSREがサポートしようと思ってもできない
- モニタリングやロギングツールは共通化

ルールの共通化

SLO(Service Level Objective)を決める

SLO: サービスが信頼できる状態かどうか判断するための指標
- 例: Gatewayで測定して､あるAPIのRequestの成功率が99.99%
- 指標がないと､何を直すのか､いつ緊急対応するのかの判断ができない

ツールの共通化

ログ: StackDriver & BigQuery, メトリクス: Datadog, エラー通知: Sentry, 当番通知: Pagerduty
Microservice starter-kitで自動で書くサービスのTeamやProjectなどが生成される

感想

流石に日本でSREの先駆けとなったメルカリの関連会社だけあって､今日の発表の中では一番Googleの教科書に近いSREをやっている印象｡SREチームは開発者のDevOpsを助けるような存在を目指しているのが特徴的だと思いました｡｢共通化｣という言葉はビッグワードですが､メルペイさんの共通化というのはあくまで｢最低限｣の部分についてであって､何でもかんでも共通化するわけじゃないです｡じゃあ｢最低限｣ってなんなのか?

運用の仕組みの共通化

サービスを作ってスケールさせていくということは､結局サービスを｢運用｣するということ｡必ず発生する｢運用｣について､ちゃんと見据えて各MicroserviceごとのDevOpsを円滑に回すための｢仕組み｣の部分をSREが担保していくというスタンスはこれから自分のチームでも取り入れていきたい｡

ITインフラにおける継続的改善の実践 - レッドハット株式会社中島倫明さん

Follow @irix_jp

ITインフラの自動化への関心

総論賛成
- QCDが改善されて嫌な人はいない
各論いろいろ
- 眼の前の作業を自動化したい人
- 全体最適化を狙う人､部分最適を狙う人
- 自動化されると仕事がなくなって嬉しい人､困る人
- 今までのやり方を変えたい人､変えたくない人
- 周辺も含めて考える人､ピンポイントに絞って考える人

ITインフラ効率化の三位一体

自動化を進める時の悩み

眼の前の作業をAnsibleなどで自動化する
- 実はそんなに難しくない
実際に取り組むと出てくる悩み
- これってほんとに動く(意図した結果になっている)んだっけ?
- 本番環境で実行して影響を与えないんだっけ?
- このPlaybookって､別の環境でも動くんだっけ?
- このPlaybook(半年前につくったやつ)って､今そのまま動かせるんだっけ?
- Ansibleをバージョンアップしたけどこれって動くの??

大半は自動化の実行､再利用､時間経過に伴う｢自動化の正しさ｣に関する悩み

自動化の正しさとは

自動化の正しさに関する悩み
手順書や仕様書は｢作業の前｣に検証･担保するためのもの
- 自動化しても設計工程についての疑問や課題がやればやるほど出てくる

TDD的なインフラへのアプローチ

自動化の正しさが自動で検証できると

精度の高い変更計画と作業が可能
- 変更に伴う影響派にを早期に検証可能(テストが何件エラーなど)
  - やる､やらない､いつやる
ノウハウの蓄積とスケール
- 運用すればするほど人に依存せずに品質が向上する
  - 確実性の高い再発防止がコードとして積み上がる
- 横展開を用意にする

｢変化｣への対応を安全で低コストに行えるようになる

変化への対応

変化への対応を前提にシステム構築･運用した方が合理的

感想

まず､第一に｢さすが教授｣という､大学で講義を受けているような気分になる発表でした｡(ま､私大学卒業してないんですけどね)
高木さんの話と同様に､｢変化｣が起こることを前提に基盤作って行きましょう､という話ですが､TDD的なアプローチをIaCでやっていくことで､｢運用すればするほど品質が向上する｣ような｢仕組み｣を作るという部分はまさにSREやQAでやっていくべき部分だな､と改めて認識しました｡

インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現という本を最近発売されたそうです!

DevOps実装者としてのSREの存在と役割 - 株式会社スタディスト北野勝久さん

Follow @katsuhisa__

スライド

DevOps実装者としてのSREの存在と役割 / class SRE implements DevOps - Speaker Deck

感想

2010年3月創業の株式会社スタディストさんは､2011年3月創業の弊社アソビュー株式会社と同じく､グロースフェーズにSREをやり始めたということもあって､すでにある程度｢散らかってる｣サービスにテコ入れをしていったその過程を発表してくださったので､とても参考になりました｡

そもそも私がこの勉強会に参加したのは､北野さんの書いた記事｢SREって何？これまでのシステム運用やDevOpsとは何が違うの？｣を読んでからTwitterなどで連絡を取ってみたあと､彼のTweetで見たからでした｡今回のスライドよりもこの記事の方が詳しいのでそちらもぜひ｡全部読むには会員登録が必要なんですが､私はこの記事を読みたくて登録しましたw

class SRE implements DevOps - SREはDevOpsの実装

DevOps
- Dev, Ops, その他チーム全体を巻き込み一体で仕事を進めるための文化運動であり方法
SRE
- ソフトウェアエンジニアがOpsを設計する際のプラクティスであり､DevOpsを実装する役割
- DevOpsほど文化的変化を前提としない

SREを含めたDevOpsを実装していくために

SREにしろTDDにしろ､もっと各論でIaCだとか､Kubernetesだとか､分析基盤だとかエンジニアなら皆やりたいですよね? でもせっかく提案してもうまくいかないって人多いんじゃないでしょうか?
その点についての一つの材料として､｢データや研究結果を示す｣という話がありました｡

私は前職の時から｢提案の仕方｣｢声の上げ方｣は下手な方で､ずっと考えてきたんですが､うまくいかなかった提案ってのは｢こんな困ってることがある｣｢こっちの方がいいじゃん｣ということだけをばら撒いてることが多かったことに最近気づいてきました｡逆に上手く行くときは､しっかりデータ出してる時だということも最近感じてたので｢カチッ｣っと音がした気がしました｡そして最近､DevOpsにさらにBizを足したような発想､つまり経営目線や他のチームや運用まで考えた提案をすることが何より大事であると考えるようになったのですが､それはまた近々ちゃんとまとめて記事書こうと思います｡
ちなみにpuppetのwhitepaperはここで毎年出てるみたいです｡(発表で紹介されてたのは2014 State of DevOps Report – Thank you | Puppet)

チームのスケールのために

｢サービスがスケールするためにはチームも個々人もスケールしないといけない｣ので､そのために何をやるのか｡

社内勉強会や社外の勉強会のアウトプットをしてストックする
- 早速週明けに開発チームに共有します
開発チームをまたいだ振り返りの実践
- 『カイゼン・ジャーニー』を読んで振り返り部をつくってみた – スタディスト開発ブログ – Medium
ポストモーテム
Twitterでの情報収集･発信
- Twitterは仕事

実際､TwitterやFacebookで北野さんに連絡取らなかったらこの勉強会にも参加しなかったし､後述する懇親会での情報交換における気付きも無かったと思います｡あ､北野さんは｢SRE Lounge｣という勉強会も主催してるそうです｡今月はもう枠埋まってましたが､次回はぜひ行きたいと思います｡

CI/CD自動化とDevOpsの抽象化の試み - Japan Digital Design株式会社 Takuya Noguchiさん

Follow @tn961ir

スライド

DevOps in JDD - Speaker Deck

主催のJDDさんの野口さん｡｢どえらい人がやってきたなぁ｣という第一印象でした｡この方Gitlabのコアエンジニアだそうです(日本では一人)｡

DevOpsとは何か､について紹介されていたドキュメント

Effective DevOps—O’Reilly E-book | Microsoft Azure
- MSから無料で落とせるよ
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

感想

Japan Digital Design 株式会社さんはMUFGグループからFintech部分を切り出して､ダイバーシティを意識して積極的に外部や他業種から採用をしていってるそうです｡週に2､3日しか来なかったり､フルリモートだったり､勤務時間も全然違う人がいたりと非同期な働き方をしてる会社｡その中でDevOpsをやっていくにあたって､とにかくGUIポチポチを無くして､コード化することで後から他のメンバーが振りかえることが出来る状態を作っている話が印象的でした｡もちろんこれは非同期な働き方じゃなくても必要ですが､非同期な働き方だからこそなおさら必要なことなんだと思います｡

ドキュメント化やコード化については最近思うところがあって､特に障害対応なんかはストックされるべきだと思うんですよね｡基本的にはサービスは一人で作るものじゃないし､｢運用｣や｢変化｣､｢障害｣が皆に等しく必ず起こります｡今日の全ての発表に共通することですが､それらの｢必ずやってくるもの｣に備えた動きをすることがSREを含めたDevOpsには必須だということですね｡そしてそういうことを考えて行くと自ずと｢提案｣する際に必要なスタンスも見えてきそうな気がしました｡

懇親会

むちゃくちゃ元気の良いJDD副社長さんの乾杯で､懇親会も執り行われました

料理も美味しかったです｡

これ､間違いなくSansanで毎月やってる社内懇親会と同じケータリング会社だと思うんですよね｡先月表参道.rbに行った時も食べましたが､このおにぎり食べるとSansan思い出します｡(まだ辞めて2ヶ月くらいですが)

懇親会では､野口さんや北野さん､JDDのエンジニアさんとも直接お話したり､他にもいろんな会社の人々と話せました｡

番外編｢懇親会での会話｣

懇親会でメルカリの@ktykogmさんとお話したんですが､その中でも特に参考になった点をいくつか｡

自動化の基準

とにかく毎日使うものは自動化したほうがいい
- 完全な自動化はまだ人類には早い
バックオフィス的な業務もzapierなどで自動化しちゃう

｢Open Door｣ - Zapierなどを非エンジニアに根付かせるにはどうしてるのか?

｢Open Door｣という話が特に興味深かったです｡どういうことかと言うと､社内勉強会や意見交換会､フリーディスカッション､｢なんでも聞いて会｣などを時間と会場を決めてかっちりとやるのではなく､｢この時間ここにいるから､いつでも好きな時に来て帰っていいよ｣というスタンスで開くような会だそうです｡
例えば､｢Zapierで定常業務などを自動化しましょう｣というのを非エンジニアにも教える時に､｢ゆるーく3時間くらい開いてるので5分くらいでもいいから聞きに来てね｣という感じで社内にアナウンスして､人が来るまで普通に仕事して､人が来たら手を止めて教えて上げるそうな｡これ､目的は｢心理的障壁を下げる｣ことで､新しいことを広めるのに心理的障壁があっては広まらないということだそうです｡なんとそういう勉強会をやったら2~3ヶ月で非エンジニアにもZapierでの日々の業務の自動化が広まったそうな｡(いくらポテンシャルの高いメルカリ社員とはいえ､すごすぎだろ｡)

もちろんこれ､勉強会だけじゃなく開発業務や新機能､その他サービスに関わるようなこともエンジニア･非エンジニア問わず､｢いつでも来てね｣というような感じで開いている会がメルカリでは多いそうです｡最近弊社でも､いろんな部署巻き込んでの会話が増えてきてますが､｢Open Door｣を取り入れるとさらに加速していろんなコラボレーション生まれそう!と思ったので早速持ち帰りたいと思います｡

メルカリでのコミュニケーション

｢心理的障壁を下げる｣というのはやっぱり大事らしく､メルカリではSlackなどで特にマネージャーなど位の高い人から率先して｢下らないこと｣などをSlackに投下したりしてるそうです｡確かに前職Sansanでも､Workplaceの個人グループとかで行われる半分雑談のような会話から生まれるコラボレーションやアイデアって多かったな､と｡

｢言っていいんだ｣という文化を作ることが大事

だそうです｡怖がってたら会社に来たくなくなりますからね｡ちなみに､これも｢研究で出てる｣そうです｡(やっぱデータ大事だー)

全体の感想

いろんな発表や懇親会での会話､それぞれに共通点があったり､組み合わさることでより理解できたり､飯も美味いし総じて良い勉強会でした｡11月にもDevOps系のテーマでJDD Studyやるそうなのでまた行きたいと思います｡

発散ブレスト会

okash1n — Wed, 19 Sep 2018 14:28:09 +0000

弊社では最近業務時間中に集まって｢発散ブレスト会｣というのをやってます｡何をやってるかというと､エンジニアやデザイナーが集まって､プロダクトの方向性や技術選択､組織などの開発にかかわるよもやま話をダラダラ繰り広げる会で､そこにはちゃんとCTOを含めた役員も数人参加してます｡

実際やってみてどうか

この取組は始まったばかりで､今日が二回目でした｡前回のテーマは｢ウォーターフォール開発とアジャイル開発｣でした｡様々なバックグラウンドのメンバーがいるので､Sier出身の人はSier時代の案件の話や､弊社が成長していく中でウォーターフォールで成功してた時期や､アジャイルで成功していた時期､または逆に失敗だったことなどを話しました｡ともするとスタートアップは目下のビジネス要件をただただ満たす為だけの｢ウォーターフォール型アジャイル開発｣になりがちだよね､という話なんかは結構みんなうなずいてた｡こういった話って､マネージャー層以外のメンバーでは割とマイナスな方向に盛り上がりやすいって思ってるんですが､弊社でのブレスト会では経営層まで含めてビジネスサイドの話と開発サイドの話を同時に出来るのが良いなと思ってます｡

今日やったこと

今日は､弊社のサービスを今後伸ばしていくために､ベンチマークとなるような｢イケてるテック企業を定めてみよう｣という会で､私の前職のSansanやNetflix, Amazon, Google, freee, メルカリなんかが上がりました｡共通してる性質として｢データドリブンであること｣､｢ビジネスに技術が直結してること｣などがあがり､結構白熱した意見交換が出来ました｡

次回やること

今日の話の中で次回以降のテーマがいくつか出てきたので紹介します｡

社員の中でユーザーと見立てた人を一人立てて､その人が画面を操作しながら実際に使ってみてる様子を眺めながらサービスの改善点をみんなで議論する
- いわゆる｢ユーザーインタビュー｣に近いものを､モブプロ的にやってみようという会
サービスのデータベースのカラムをざっくりなめてみよう会
- どんなデータが取れているのか､取れていないのかを把握して､サービスの改善に活かすようなデータベースづくりの足がかりとする

後記

実は昔､あらゆることを書く雑多なブログをやっていて､ひどいときは一日に20件ほども更新するような時期が私にはありました｡最近思うところがあって､その頃のように｢クオリティの低さ｣を恐れずにどんどんアウトプットしていこうという気がまたわいてきたので､こういった適当な記事もどんどん書いていきたいと思います｡

Github Flowの覚書

okash1n — Tue, 04 Sep 2018 07:35:26 +0000

最近はRailsチュートリアルやProgateのRails講座をやっています｡お恥ずかしながら､あまり仕事でgitを使うことが無かったので､Github Flowなどもよく理解していません｡というわけでProgateのRails講座をブラウザでやりながら､ローカルでもRails立ち上げて､1問ごとにブランチ切って自分でプルリク出して開発してみることにしました｡
やっていく中で結構覚えてきたので､メモとして残しておこうと思います｡

Github Flowの大まかな流れ

大まかには下記のような流れです｡

masterブランチから新しくブランチを切る
変更を加える
commitする
pushする
プルリクエストを出す
レビューしてもらう
問題なければマージする(してもらう)
リモートブランチを削除する

詳細な手順

ここでは､プルリクエストの部分以外はローカルからコマンドでやる方法を記載します｡
新しい機能(new-feature)を追加します｡コマンドは全てプロジェクトのルートディレクトリで実行しているものとします｡

ブランチの作成

ブランチを切ってそのブランチに移動する
- ブランチ名はチームのルールに従って､追加する変更がわかりやすい名前にする(Jiraなどのタスクナンバーにする場合も)
- git checkout -b new-feature

> git branch -a
  master #ローカルのマスター
* new-feature #現在のブランチ
  remotes/master #リモートのマスター

変更からプルリクまで

変更を加える
commitする
- git add .
- git commit -m "新しい機能を追加"
リモートブランチにpushする
- git push origin new-feature

> git branch -a
  master
* new-feature #現在のブランチ
  remotes/new-feature #リモートに同名のブランチが作成された
  remotes/master

プルリクエストを出す
- ブラウザでリポジトリを開き､リモートブランチ(new-feature)に対しプルリクエストを出す
- pushした直後であればリポジトリのトップ画面にCompare & pull requestというボタンが出ている
レビュアーにレビューしてもらう

変更の取り込み

自身でマージする場合は【自分でマージする場合】まで飛ばしてください

他の人(レビュアーなど)がマージする場合

> git branch -a
* master
  remotes/master
  remotes/new-feature # プルリクのコミット

ローカルのorigin/masterを更新する
- git fetch origin

参考
git fetchの理解からgit mergeとpullの役割

ローカルにプルリクのブランチを持ってくる(リモートブランチからブランチを作成)
- git checkout -b new-feature origin/new-feature

> git branch -a
  master
* new-feature
  remotes/master
  remotes/new-feature

ローカルのorigin/masterをmasterにマージ
- git merge master
【自分でマージする場合】に進む

自分でマージする場合

masterに移動
- git branch master

> git branch -a
* master #現在のブランチ
  new-feature
  remotes/master
  remotes/new-feature

変更(new-feature)をローカルのmasterにマージする
- git merge --no-ff new-feature

> git branch -a
* master  #同じコミット
  new-feature #同じコミット
  remotes/master #一つ前のコミット
  remotes/new-feature #同じコミット

--no-ffなどのマージオプションは下記が詳しかったです｡

図で分かるgit-mergeの--ff, --no-ff, --squashの違い - アジャイルSEを目指すブログ

gitのmerge --no-ff のススメ

ローカルのmasterをリモートにpushする
- git push origin master

> git branch -a
* master  #同じコミット
  new-feature #同じコミット
  remotes/master #同じコミット
  remotes/new-feature #同じコミット

ブランチの削除

Github Flowに則るのであれば､リモートのmasterブランチは常にデプロイ出来る状態なので､この時点でCircleCIなどでビルドが走ってデプロイされるケースがあるかもしれません｡リモートとローカルのnew-featureブランチは不要になるので削除しておきましょう｡

ローカルのブランチ削除

git branch -d new-feature

> git branch -a
* master
  remotes/master
  remotes/new-feature

リモートのブランチ削除

git push --delete origin new-feature

> git branch -a
* master
  remotes/master

以上です｡実際に業務で使ったわけではないので､おかしな部分があるかもしれません｡(特にレビュアーの立場のところは実際にやってないので｡｡)
おかしな部分があればご指摘ください｡

Forem: okash1n

｢最新DevOps事例勉強会｣に行ってきました

概要

DevOps on Merpay Microservices - 株式会社メルペイ 高木 潤一郎さん

スライド

SREってなんだっけ??

メルペイのアーキテクチャ

Merpay API Gateway

運用の仕組みの共通化

ルールの共通化

ツールの共通化

感想

ITインフラにおける継続的改善の実践 - レッドハット 株式会社 中島 倫明さん

ITインフラの自動化への関心

ITインフラ効率化の三位一体

自動化を進める時の悩み

自動化の正しさとは

TDD的なインフラへのアプローチ

自動化の正しさが自動で検証できると

変化への対応

感想

DevOps実装者としてのSREの存在と役割 - 株式会社スタディスト 北野 勝久さん

スライド

感想

class SRE implements DevOps - SREはDevOpsの実装

SREを含めたDevOpsを実装していくために

チームのスケールのために

CI/CD自動化とDevOpsの抽象化の試み - Japan Digital Design株式会社 Takuya Noguchiさん

スライド

DevOpsとは何か､について紹介されていたドキュメント

感想

懇親会

番外編｢懇親会での会話｣

自動化の基準

｢Open Door｣ - Zapierなどを非エンジニアに根付かせるにはどうしてるのか?

メルカリでのコミュニケーション

全体の感想

発散ブレスト会

実際やってみてどうか

今日やったこと

次回やること

後記

Github Flowの覚書

Github Flowの大まかな流れ

詳細な手順

ブランチの作成

変更からプルリクまで

変更の取り込み

他の人(レビュアーなど)がマージする場合

自分でマージする場合

ブランチの削除

ローカルのブランチ削除

リモートのブランチ削除

DevOps on Merpay Microservices - 株式会社メルペイ高木潤一郎さん

ITインフラにおける継続的改善の実践 - レッドハット株式会社中島倫明さん

DevOps実装者としてのSREの存在と役割 - 株式会社スタディスト北野勝久さん