2019-03-26 NoOps Meetup Tokyo #5
2019/03/26 に開催された NoOps Meetup Tokyo #5 のイベントレポートです。
●イベント概要
NoOps = No "Uncomfortable" Ops
NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう！」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。
NoOps Meetup Tokyo #5 では、業界の第一人者のみなさんに登壇いただき、それぞれの視点でのNoOpsをお話いただきます。
■オープニング
岡 大勝 さん [ NoOps Japan 発起人 ]
●はじめに
・メンバーが1,000名超えました！
・NoOps Definitionを公開しました！
https://github.com/noopsjapan/community/blob/master/DEFINITION.md
●前回のおさらい
・Cloud Native BuildpackでToil減らしていこう
・シンプルに考えよう Zero Trust Network
・Zero Trust Network アーキテクチャ
・Elastic Stackでマイクロサービス運用を楽にするには？
今日は楽しんでいってください！
■NoOps に入り込む基盤の負債
坂部 広大 さん [ Wantedly ]
●wantedly
企業と人が出会う場
人と人が出会う場
●history
・Wantedly Vist
mobileシフトのタイミングで東京リージョンにした
chef -> dockerfile直接
去年で全部k8sに移行した
・wanbtedly people
k8sのPOCが終わって本格的に
・MLOps, DataOpsとかも出てきて
より動的なアーキテクチャに動いてきている
・そういえば毎年基盤を入れ替えている
・2017年 ネットワークが複雑になっていることに気づいた
-> 統一しないと難しい。全部入れ替え！
・2018年 k8s！これで終わった！のハズが
・2019年 etcdを3にverup
●リポジトリ = サービスで回している
・インスタンス数のバッファが要らなくなってた
-> Nodeが減ってきている
・とはいえ、コンテナが年に1000とかで増えている
・1hostに80コンテナくらい
●結果的に毎年総入れ替え
・技術的にやらないといけないはそんなになかった
・減価償却が早い
翌年には変わっている
生産性が何%上がるから妥当などを考える
・インシデント対応でも
・シンプルな裏側ですごいマシンが動いているを目指して
●インフラチームのミッションを再定義
・why
wantedlyの創造的な活動を支える
・how
プロダクトとビジネスに貢献する
・what
site reliability
dev productivity
architecture as strategy
・あえてインフラという言葉を使っていない
●Infra(NoOps)の負債
・課題を見極める
・他のチームでも起きているものではないか？
・何を解決したかったのか、後で見てわからない
whyと目指したい方向性が必要
自分たちがやっていることが独自になっていて、技術レベルを下げてないか？
・負債は常に起こり得る
●課題を削ぎ落とす
・課題を見極めることに時間をかけている
運用で課題が増えないか？
コードを書かずに避けられる方法はないか？
・一言でまとめるようにしている
一点集中するためプロジェクトとして成功率が高い
●哲学、原理原則、ベストプラクティス
・名前をつけたがるオジサマ方が沢山がいる
・原理原則を書いてくれている物が増えている
・kubernetes/kubernetesのデザインドキュメントに初期のコンセプトがまとまっている
●ゴールの法則
・ツールを入れたからって一気に解決することはない
・POCで見極める
●技術選定
・原理原則に合うツール
why-how-whatを把握
自分たちで継続的に改善できるか
・攻めと守りを意識する
・自分たちでも正しいのかはわからない
・最小公約数で汎用的なツール
●事例：kubernetes
・2015から試しはじめて
・2018で切り替え
●事例：observability改善 2019
・統計的に把握するためのPOC
・信頼性のために追加したコード
-> ライブラリ作成中
・ライブラリをつくると、言語が縛られる
-> sidecar pattern
7月のイベントで発表予定！
・speedcurve.com
表示速度
デプロイ前後の差分
・performance.now()
参考にしてます
●MLOps and DataOps
・データサイエンティストとデータエンジニアの棲み分けも話題に
・いろいろネタも出てきました
●まとめ
・シンプルにつくる
・テクノロジーライフサイクルに合わせて選ぶ
■CircleCI 2.0を支えるインフラとSREの役割
金 洋国 さん [ CircleCI Japan ]
●CircleCI
・1.0 からの移行ありがとうございました！
LXDベースのCI/CD。先駆的だった！
・3/15 に1.0が、めでたくRIP
hubotコマンドで手動でスケールアウトインしていたw
この苦労を知っているエンジニアが1インスタンスずつ停止した
・2.0
120万ビルドをさばいている
●CircleCI Japan
・CircleCI発の海外支社
・日本語で質問できます！
一番の問題は知られていないこと
●Hop-on!
・電動キックボード
・日本ではまだ非合法。これをどう合法にするか
・マリカーのキックボード版を準備中
●CircleCI2.0のアーキテクチャ
・マイクロサービス
・AWS
一部GCP
・Clojure, Go, TypeScript
世界中のclojureエンジニアが集まってます
・コンテナベース
・Kubernetes/Nomad
●2つのクラスタ
・k8s: マイクロサービスが動いている
・Nomad: ビルド実行のマシン
・ビルドは任意のコードを実行するということ
クラスタを分けることでセキュリティを担保
●kubernetes
あまり尖っていることはやっていなかった。
・すべてのマイクロサービスが動いている
・CoreOS
・EC2
・Terraformで管理
●Nomad
・hashi corp製で安定している
・Server = k8s master
コーディネーション
・Client = k8s worker
処理を実行
・バッチジョブとしてビルドを実行
CircleCIの処理は、長くても数時間
・1コンテナ = 1 Nomad Job
1つのビルドで複数のコンテナを動かせる
●ビルドが実行されるまで
・k8s -> Nomad ビルドリクエスト
・Nomad Jobができる
・Dockerコンテナの起動
・ビルドの引数でGo製の build agentを起動
・ビルドのコマンドを逐次実行
・Nomad -> k8s ログを送信 -> UIに表示
●なぜ別のクラスタ？
・2016時点で、バッチ処理は k8s < Nomad
・現時点ではk8sも良くなっているらしい
・アーキテクチャがシンプル: 1バイナリ！
・Consul, Terraformなどと親和性が良い
-> buildersconで詳しく話してきました
●SREチーム
・SREチーム構成
エンジニア 140 : SRE 9
4ヶ国
時差がきつい
朝2時からミーティングなど
・ボーイング方式
767をつくるときにコスト削減でグローバルなチームを組んだ
常に誰かが働き続けられる -> スピードを上げた
小学生向けの本に書いてあった
-> 障害対応の負荷がなくせる！
・コミュニケーション
基本はslack
噛み合わないときは 10秒でも zoom
1年に1回 All Hands
半年に一回 Small Hands: 慰安旅行的
・役割
安定したインフラ運用
プロダクトの開発に集中できるように
必要に応じてペアリング、コードレビュー
障害対応
●障害対応フロー
・障害かな？
#investigation チャンネル
・ユーザー影響あり
#incident
強制的に @メンションされる
zoom開始
・Incident Commander、Note Takerを任命
・20分ごとに状況をアップデート
・30分様子見して問題なければclose
●役割
・Incident Commander
現場指揮官
消防などである役割
必要なリソースを確保する
SREが多いけど、別ロールの人も
・Note Taker
記録係
●Postmortem
・障害を発生した人が作成
・プルリで管理
●課題
・ホスティング型k8sサービスへ移行
GKE / EKSで検討中
・チームの拡大
まだまだカオスエンジニアリングをやるレベルではない
SRE Team in Japan メンバー募集中
■スポンサーセッション
●株式会社ギックス / GiXo Ltd.
・戦略コンサルティング
・データアナリティクス
「何を成し遂げたいのか」のためのデータ分析基盤
・岡さんが技術顧問！
新しい技術もいろいろ使います
●wework
・オフィスに対するtoilはありませんか？
ファシリティ準備が面倒
10年先を見据えて賃貸契約？
外部の人とのコミュニケーションが取れない
コーヒー買いに行くの面倒
・やりたいことに集中できる環境を
・Do What You Love
・コミュニティでも使えます
・ケータリングはFoodist Linkさん
●Forkwell
・今日はビデオレターで
・エンジニア応援団です！
・2018年は 300以上の勉強会をサポート
また出たな Forkwell
■前回の様子
■感想
ゴールデンサークルで組織と技術のマッチ具合を判断する考え方や、テクノロジーライフサイクルを前提に減価償却で価値を捉える流れ
時差を活かすボーイング方式の働き方、障害対応フローのノウハウなど
これからの活動で活かせそうな発想のきっかけを沢山いただけました！
登壇者の皆さんありがとうございました！！運営の皆さんお疲れ様でした！
いいなと思ったら応援しよう！
