Hatena Engineer Seminar #11
マンガチームとDevOps
DevとOpsを近づけよう。
DevタスクメインのチームがOpsする。
でも問題が
知見、負担が個々のエンジニアに集中。
プロダクトオーナーシップ
SREチームに全部まさせるのではなく、各チームのエンジニアができるといいね。
実際のところマンガチームでは開発優先でそこまでまだ進んではいない。
ミドルウェアのクラウド移行、サーバ構成変更とかはむずかしい。
開発に近いところからやっていく。
新しいサイトの立ち上げ時のドメイン、cert、CDN、ALB、S3とるとか。
以前はSERにお願いしてたが、チームでできるといいよね。
SREと一緒にオペレーションしていく。
スケジュールに余裕がある時にペアオペ。
これによりチームが知見を獲得。
チームのエンジニアが実際の作業をして、SREは見守り、解説をする。
SREにあるドキュメントを読む。
ペアオペする。
最終的にチーム向けのドキュメントを作る。
タスクの作業がチーム内で完結したりしてよい。
手作業を無くす。 → 自動化
S3バケットの新規作成とか
チーム内のレビューだけでなく、SREの人のレビューも。
YAML書くだけになると誰でもできるようになって便利。
このへんの話の逆からの視点、SRE本にありましたね。
データ基盤を作るのに使うようなサービスは単発で使うだけでも便利。
大統一データ基盤のようなものがなくても、単発で使うと便利。
グロースハック
「数字をちょっと見てみたい」みたいなとき……
データ基盤がなかったら サービスのDBやログから集計することになる。
以下のような感じになる。
SQLを叩く。
スクリプト書いて回してスプレッドシートにのっける。
これを定期的に回してバッチで……。
いろいろ辛い。
可視化とか共有とかどうする？
スクリプトのメンテとかどうする……？
ここでbq!
銀の弾丸
とりあえず既存のDBからbqにバルクロードしてみる。
たいしたことない量(とは？)なら、とりあえずそれでなんとかなる。
bqなら適当に集計したり、google spreadseetにエクスポートしたり……。
ログはどこにある？
bq、RedShift、S3とか
S3にあるならAmazon Athenaでできる。
grep as a Service
S3のファイルを指定してフルマネージドでできて、テーブル作ってクエリするだけ。
CSV/TSV/JSON……、いろんなフォーマットをパースできる。
Hive形式のディレクトリで掘って保存すると、自動でパーティショニングできて便利。すごい。
symlinkでなんとかなる。
安い。
システム基盤としてのAWS活用
システム基盤とは？
サービス開発の速度を向上させるようなツール
手作業はつらい。
どんなAWSサービスを使う？
lambda 連携の自動化
サーバーレス
可用性、保守性
サーバーレスアプリケーションモデル
AWS公式によるフレームワーク
スケジュールされたイベント
今まではSlack通知からのissue起票からの対応
CloudWatch Eventsで受けて、自動でgithub issue起票。
バッチサーバを置かなくていい！！！
Let's Encryptのcertの更新自動化
3ヶ月に1度するの大変。
cw eventsを発行すると、lambdaで実行されてS3に置かれるようにする。
便利そう。
去年のアドンベントカレンダーに詳しいことあるよ。
OSS化されててはてなのレポジトリにある。
他の人がメンテできるようにする。
ドキュメントをしっかり用意。
なるべく公式のツールを使う。
スコープ、責任境界
APIにより連携がしやすいので、どこまでをやるかをちゃんと決める。
これからのシステム基盤
ガイドラインを作る。
治安が崩壊しないように。
マルチアカウント対応
サービスごとにaws accountわかれたらどうするか。
たいへんそう……。
まとめ
lambda
CFを共通言語にする。
サーバレス
AWS固有のこととか。
MackerelをオンプレミスからAWSに移してからの1年半を振り返る
tsdb
オンプレでスタートしたが、サービスが成長すると大変。
Graphiteの運用が大変。
スケールアウト、冗長化がたいへん。
AWSへ。
移行に1年ぐらい。
tsdbの検証が大変だった。
EBSではiops足りない。
DynamoDBを軸にdiamondという名前でつくった。
「次世代Mackerelプロジェクト」という名前をつけると、次世代でしたいことがどんどんでてくる。
スコープを絞る。
まずはEC2に全部載せる。
切り分け可能なところは切り分ける。
リリース粒度を下げたりとか。
普通のこと。
パーツごとにちょっとづつ移行していく。
移行オペとしてはDB切り替えはヘビー。
オンプレではなくAWSになったことで、開発の時の検証とかのスピードも上がった。
とはいえ理想郷ではない。
さまざまな障害がある。
より抽象度を上げた感じでいけるといいかも。
AWS APIをもっと活用していけるといいね。
MySQL自前運用やめてAurora導入する話
ある日突然MySQLが乗ってるDom0(ハードウェア)が死ぬと。
半日がかりになり大変。
プロダクトオーナーシップ
とは言え本当にMySQL運用をチームでやりたいのか？
そこでオーロラへ。
運用をAWSに任せて自分たちは自分のドメインに集中。
「チームメンバーがオペレーションできるようにしとかないと、課題の半分しか解決していない」
説明会とかハンズオンとかで慣れてってもらう。
オペレーションの必要が無くなるので、逆に運用の距離が出てしまう(わからくなる)。
むずかしいよね。