2019の22日目として書いております。今回は、プロダクトがアーリーな時期のSRE/devopsとの向き合い方の一例として、現在取り掛かっているチームへのIaC文化の導入についてお話しさせていただこうと思っております。自己紹介Wano株式会社のnariと申します。サーバサイドエンジニアとして働いていています。BotやAppを作ったり、CI/CD改善・IaC・モニタリング最適化に取り組んだりしています。VideoKicksというミュージックビデオ納品代行サービスを展開しています。等のストアにミュージックビデオを一括配信できます。productチームのエンジニアはEMを合わせて5人。これからグローバル対応(詳しくはまだ明かせない)する案件がもう走っていて、USとのmeetingや折衝に追われる毎日です。現状、このプロダクトのインフラは、大部分がGUIによってAWS上に構築され、管理されています。プロダクトとしてアーリーな時期(リリースから1年くらい)であり、信頼性や基盤に対して専門のチームを付けたり、大きなリソースを割くことができない状態です。(ビジネスモデルとして確立するまで、どんどんと新規機能をリリースする必要がある)しかし、今までCDNなど以外は東京リージョンに閉じて展開していたインフラリソースを、グローバル対応とともに各リージョンに複製/展開し管理する必要が出てきたため、このままのGUI管理では限界を感じインフラをコード化(IaC)して管理していく方向に転換しようとしています。Qiita)カレンダーの他の記事のように、グロース期+開発者と運用者がプレイヤーとして分かれているというのがSREを考える上でよくあるパターンだと思うのですが、ベンチャー+プロダクトがアーリー期+開発者が運用も兼ねるチームに置いても、SRE/devopsのタネを蒔いていく必要があるよねという話をしたいと思います。目的、なぜやらなければならないか、どう実現していくかを共有するためのDocsを作り、meetingにて共有/議論しました。目標に関しては、USプロジェクトの開発フェーズ開始前に、複製していくCoreの部分(ネットワーク、ルーティング、ストレージ、納品サービス)のIaCが完了し、かつチームとしてIaCの知見/経験が蓄積されていることに設定しました。CDKがGAしたばかりでプラクティスがまだまだ確立していない+対応していないリソースもあることからTerraformを選択しました。この提案の際に一番気をつけたことは、現状(今まで開発者がやってきたこと)を否定しないことです。GUIによるインフラの構築は、シード〜アーリーにかけては止むを得ない(会社としてIaCの知見が溜まっていなかったりすると)し、そちらの方が初速が出るという判断は間違っていないというのが僕の見解です。その中で、これからグローバル展開、グロース期に入っていくといった中で、現状のままでは運用が困難であり、やっていくべきだよねという伝え方をしました。(技術や方法は、フェーズや状況によって正解は異なるので、一概に否定できるものではない)今までビジネスを支えてきた開発者に敬意を払いながら、ドラスティックに運用を変えるものを一緒に導入していこうという姿勢でやっていっています。IaCは銀の弾丸ではなく運用を間違えるとコストが増えるだけになってしまいがちなので、常にベストプラクティスを求め柔軟に変化していく必要性も伝えました。(現状のmodule/コンポーネント設計にこだわらない、terraformにこだわらない、100%IaCしなければならないわけではなくROIと相談して決定する)また、ここで使用したIaC化のデザイン案は、進めていくたびに立ち戻り修正を繰り返しています。記事の共有グループの別プロジェクトでインフラ構築をほぼ全て任されたことがあり、その際にほぼ全てのリソースをterraformでIaCして作ったのでその際の知見を社内のDocbaseや、Qiitaにまとめて共有していきました。自分のチームだけではなく、グループ会社からもらった案件の引き継ぎをしやすくすること、他のグループ会社への啓蒙の意味も兼ねていたのでグループ全体で実施することにしました。Codeから引用したりしながら説明し、その中でのTerraformの立ち位置、他のIaCツールとの比較説明を行いました。instanceを立てたり、moduleを使用する形にリファクタするところまで経験してもらいました。credential周りやもろもろでエラーが出たりしていたので、そこはサポートしながら、terraformの基本記法、コマンドを理解してもらうところまでやりました。最後に、ハンズオンでは共有しきれなかった、実際に開発/運用する際に必要になるtipsや、参照すべきdocsや本の紹介などを行い、勉強会を終えました。Qiitaこの会を開くことによって、チーム内/社内だけにとどまらずグループ会社全体にIaCへの認識を浸透させられたのはとても大きかったと思います。(今自分がやっていることに対して理解をしてもらえ、背中を押してもらえるようになった)これからも継続して、こういった会社間で開かれた勉強会を開催したり、他の人を巻き込んで一緒にやっていきたいと思っています。今回はCI/CDともにCodebuildで構築、ソースリポジトリはBitbucketCIではfmtチェック。APIのGoクライアントで使えるものがなく、そこから自分で作るしかないなぁと思っているステータスで止まっています。Actionsで簡単にCI/CD構築できるっぽいのでそちらをご活用いただくと良いと思います。Deckこれからの展望IaCIaCに関しては、現在ステージング・開発環境リソースのIaC化に着手しており、そちらはもうそろそろ落ち着きそうです。これが終わり次第、本番環境のIaCを全てのdeveloperに対してタスクを振り分け、そこらへんはマネージしたりサポートしながら遂行して行こうと思っております。(タスクをこなすのが、一番早くスキルが身につく)まだまだ道半ばなため、これからも継続して浸透させていく施策をどんどん打っていきます。US/グローバル対応の際はかなり様々な知見が得られると思いますので、そちらの社内外にシェアしていきたいと考えております。NEXTの運営させていただいており、優秀なSREエンジニアに日々刺激を受けています。いったコミュニティで吸収した知識もどんどんプロダクトにfeedback出来たらなと考えています。engineering、SLI/SLOの最適化etc)ただ、もちろん自分はいち開発者であり、そこに全てのリソースが避けるわけではないので、引き続きUS展開を中心にプロダクトの設計/実装もどんどんやっていきたいと思います。(開発者としての目線、スキルも養っていくことで運用をデザインしていく力も向上させていけると思っている。)最後にSREじゃないやつの記事で申し訳ありませんが、SREの思想はSREのためだけではないというのが僕の考えなので、そこらへんを感じていただけたなら幸いです。devopsしていってるのでSREっぽいこともしている感じ)これからも、アーリーな時期でのSRE/devopsとの向き合い方・タネの蒔き方を諸々チャレンジし、紹介できればと思っています。upLoginユーザーは見つかりませんでした。