Speee Cafe Meetup #03
Speee Cafe Meetup #03に参加してきたぞい！
会場はSpeeeさんのカフェスペース(で合ってるのかな)。オシャレ！
プロジェクタ前のスペース以外にテーブルが4つくらいあって、それぞれSpeeeのアプリ、基盤、サーバサイド、フロントのエンジニアの方が常駐していました。
私は基盤テーブルに居座りました。( ･´ｰ･｀)
発表の開始まで20分ほど歓談タイムがあったのでコーヒーとビール飲みながら雑談していました。発表の流れは以下。
- クラウド&コンテナ活用でDevOpsを加速させる！
- 技術基盤チームでの2年間とこれから
- Speeeで採用した監視ツールの選定プロセス
- Serverless Frameworkを本番環境に投入するために
以下メモ！
クラウド&コンテナ活用でDevOpsを加速させる！
基盤チームの誕生と、基盤チームがやってきたことの話でした。スライド公開されるしあんまりメモ意味なかったぴょん！
そもそもなぜ基盤チーム誕生したか。以下のようなつらみを抱えていた。
- サービスが多く、約250リポジトリもある
- 蜜結合（サーバはオンプレミスで、1サーバにいろいろ乗ってる構成）
- レガシーに苦しむ
- 開発効率を上げたい
- 手作業で構築、アプリもリリースなど、手作業が多い
- 開発とインフラが別部門でインフラの依頼待ちとか、意見の対立もあった
- etc...
それらの課題を解決するためのチームとして「技術基盤チーム」を発足した。開発＆運用の効率化を進め、つらみを解消するという目的を掲げている。
技術基盤チームはインフラ部門・開発部門とガッチリ組んで作業している。
やったことは、サーバをGCPやDockerに移行したり、モニタリング環境の整備、ログ調査基盤の整備をやってきた。Chefも導入したが、浸透しなかったとのこと...。
最終的には1コンテナ1プロセス、デプロイがシンプル、再現性(ローカルと本番環境で同じ動き)が高いのでコンテナを採用。
GCPをつかっているのでコンテナのホストにGCEを採用。Kubernetesが強力で良いとのこと。そして部門毎に以下のような領域をもつようになった。
インフラ部門はコンテナの外側に責任を持っている。
- サイジング、クラスタ作成など
開発部門はコンテナの内側に責任を持つ。
- バージョナップ、リリースなど
苦労した点は、
- コンテナの特性を活かした設定
- Kubernetesの事例が少ない
- 開発者と運用者の意見の相違
とのこと。
**「開発効率向上はサービスの成長のため」**と言う言葉が印象的だった。
感想
懇親会で質問しました。
Q. 複数サービスあるとのことでしたが、サービスのコンテナ化とか、そのサービスのチームに対して基盤チームはどのように働きかけていったのでしょうか。とっつきやすいチームでまずは導入していき広めていく、とか。
A. 基本的に基盤チームでどんどん進めていって、お膳立てしたものをサービスに展開していった感じ。
ﾅﾙﾎﾄﾞ… コア開発チームはどうしても手が回らなかったりしますからね...。真似してこう。
あとこの事例の基盤チームは、「異なる部門間の橋渡し」的な役割も大きかったのかな〜と思った。
技術基盤チームでの2年間とこれから
ペパボ技術基盤チームは見ている範囲が大きい印象でした。
ペパボの基盤チームの役割。
- 複数のサービスがあるが技術部（技術基盤チーム、インフラグループ、情報システム）が横串でみてる
- 「全社を横断する技術課題を解決する」
- データセンターの移設とか統一基盤、CIなど
- 「事業部固有の大きな課題の解決」
- etc
いい感じにバーンとする。
- 大きな課題を分解し、着実に成果を出し続ける
- 視点高くして広範囲の人を巻き込む
- 成果やプロセスを社内外に公開する
また、事業部門固有の課題(技術的課題？)を解決する人としてCTL(Chief Technical Lead)がいる。部門CTOみたいなイメージ。
- 基盤チームの「部門の大きな課題を解決する」という部分を抜き出したような感じ
感想
大きな課題を分解し、着実に成果を出し続けるが印象的でした。組織構造は会社の規模などにもよるので真似出来ないですが、技術基盤チームの方向性としてはこれが重要そう。
Speeeで採用した監視ツールの選定プロセス
Speee開発基板部についての話でした。
ミッション「全事業部の開発効率をあげる」
監視周りや障害対応周りで困っていた。そこで基盤チームでいい感じのSaaS探しと検証を行った。
- エラー監視はエラー数とエラーリミット(課金)の兼ね合いと、ログバックの対応でセントリー採用
- リソース監視ではデータドッグとmackerelで迷った
- それぞれの営業とも相談
- mackerelのAWSインテグレーションはEC2とかRDSも課金対象だけどデータドッグはEC2だけ
やりたいことではどちらもそんなに変わらないけれど、安さでデータドッグにした。
監視用のディスプレイがあり常にグラフが表示されている。良い！
失敗例。
- データドッグのAWSインテグレーションでタグ指定しないと全EC2が対象になり課金で死ぬ
ので監視対象の監視をしている！
感想
基盤チームはやはり、
- 監視基盤整備
- ログ基盤整備
- データセンター、IaaS周りの整備
を推進する事例が多いな！
Serverless Frameworkを本番環境に投入するために
FaaSについてちゃんと聞いたのははじめてでした。φ(..)メモメモ
- FaaSとは関数を実行するインフラを提供する
- 関数とは1つの入力と出力を持ち、対象の状態を変更するもの
関数を実行するインフラを自前で管理しなくて良いことによって管理コストを低く出来る。それがサーバーレスの利点。
ではそれらいろんなFaaSを組み合わせた構成を管理しようとすると...。
地獄。
サーバーレスフレームワークを使うことでいい感じに抽象化され、管理しやすくできる。
感想
サーバーレスはサーバーレスで収まればすごいきれいな印象(こなみ)。サーバーレスまともに触ったこと無いので(S3とか単体で組み込むことは有るけど)触っていきたい。
懇親会
ピッザ食べながら閉会時間すぎるまでお話しました。
まとめ
事例が聞けたので良かった。全体的に、ある大きな課題(チーム関係なくある問題)に対してその問題を分解し、やっていくチームが基盤チームみたいな印象があった。
あと技術基盤チームがどうやって課題を拾い上げていくかみたいな話も聞いてみたいと思いました！