はじめに

こんにちは！こちらはSRE Advent Calendar 2019の22日目として書いております。
今回は、プロダクトがアーリーな時期のSRE/devopsとの向き合い方の一例として、現在取り掛かっているチームへのIaC文化の導入についてお話しさせていただこうと思っております。

自己紹介

Wano株式会社のnariと申します。サーバサイドエンジニアとして働いていています。
SREというroleでは働いていませんが、もともとDeveloper Productivity/スケーラビリティ/信頼性を向上させる基盤作りというのが自分の興味領域ということもあって、業務円滑化のSlack BotやAppを作ったり、CI/CD改善・IaC・モニタリング最適化に取り組んだりしています。

プロダクト紹介

Wanoグループでは　VideoKicksというミュージックビデオ納品代行サービスを展開しています。
現在は、グループ会社である TuneCore Japan経由でログインでき、Apple , Line Music , Gyao , MusicJp, Recochoku 等のストアにミュージックビデオを一括配信できます。

そして、VideoKicks productチームのエンジニアはEMを合わせて5人。これからグローバル対応(詳しくはまだ明かせない）する案件がもう走っていて、USとのmeetingや折衝に追われる毎日です。

現状、このプロダクトのインフラは、大部分がGUIによってAWS上に構築され、管理されています。また、まだまだプロダクトとしてアーリーな時期(リリースから1年くらい)であり、信頼性や基盤に対して専門のチームを付けたり、大きなリソースを割くことができない状態です。(ビジネスモデルとして確立するまで、どんどんと新規機能をリリースする必要がある)

しかし、今までCDNなど以外は東京リージョンに閉じて展開していたインフラリソースを、グローバル対応とともに各リージョンに複製/展開し管理する必要が出てきたため、このままのGUI管理では限界を感じインフラをコード化(IaC)して管理していく方向に転換しようとしています。(そのファーストステップの開発・ステージングリソースのIaCのテクニカルな話は terraform Advent Calendar 2019 15日目でしています -> 本番環境リソース以外をTerraformでIaCして別アカウントに移す方法 - Qiita)

カレンダーの他の記事のように、グロース期+開発者と運用者がプレイヤーとして分かれているというのがSREを考える上でよくあるパターンだと思うのですが、ベンチャー+プロダクトがアーリー期+開発者が運用も兼ねるチームに置いても、SRE/devopsのタネを蒔いていく必要があるよねという話をしたいと思います。

どう浸透させていっているか

1. 計画概要の提案・共有

目的、なぜやらなければならないか、どう実現していくかを共有するためのDocsを作り、meetingにて共有/議論しました。

目標に関しては、USプロジェクトの開発フェーズ開始前に、複製していくCoreの部分(ネットワーク、ルーティング、ストレージ、納品サービス)のIaCが完了し、かつチームとしてIaCの知見/経験が蓄積されていることに設定しました。

どう実現していくかの技術選定に関しては、グループ会社のある案件で少し知見があったこと、比較検討していたAWS CDKがGAしたばかりでプラクティスがまだまだ確立していない＋対応していないリソースもあることからTerraformを選択しました。

この提案の際に一番気をつけたことは、現状(今まで開発者がやってきたこと)を否定しないことです。GUIによるインフラの構築は、シード〜アーリーにかけては止むを得ない(会社としてIaCの知見が溜まっていなかったりすると)し、そちらの方が初速が出るという判断は間違っていないというのが僕の見解です。その中で、これからグローバル展開、グロース期に入っていくといった中で、現状のままでは運用が困難であり、やっていくべきだよねという伝え方をしました。(技術や方法は、フェーズや状況によって正解は異なるので、一概に否定できるものではない)

今までビジネスを支えてきた開発者に敬意を払いながら、ドラスティックに運用を変えるものを一緒に導入していこうという姿勢でやっていっています。

また、IaCは銀の弾丸ではなく運用を間違えるとコストが増えるだけになってしまいがちなので、常にベストプラクティスを求め柔軟に変化していく必要性も伝えました。(現状のmodule/コンポーネント設計にこだわらない、terraformにこだわらない、100%IaCしなければならないわけではなくROIと相談して決定する)

また、ここで使用したIaC化のデザイン案は、進めていくたびに立ち戻り修正を繰り返しています。(feedback、振り返り)

2. 知識の共同化

2.1 記事の共有

グループの別プロジェクトでインフラ構築をほぼ全て任されたことがあり、その際にほぼ全てのリソースをterraformでIaCして作ったのでその際の知見を社内のDocbaseや、Qiitaにまとめて共有していきました。

その際のQiitaの記事の一部:

2.2 勉強会の開催

自分のチームだけではなく、グループ会社からもらった案件の引き継ぎをしやすくすること、他のグループ会社への啓蒙の意味も兼ねていたのでグループ全体で実施することにしました。(弊社はサテライトという仕組みをとっており、６社のグループ会社に分かれています)

勉強会の流れとしては、まずはじめにIaCそのものの歴史、メリットデメリット、種類をO'Reilly Japan - Infrastructure as Codeから引用したりしながら説明し、その中でのTerraformの立ち位置、他のIaCツールとの比較説明を行いました。

その後、ハンズオン形式の部分を設け、実際にterraformをインストールして、ec2 instanceを立てたり、moduleを使用する形にリファクタするところまで経験してもらいました。aws credential周りやもろもろでエラーが出たりしていたので、そこはサポートしながら、terraformの基本記法、コマンドを理解してもらうところまでやりました。

最後に、ハンズオンでは共有しきれなかった、実際に開発/運用する際に必要になるtipsや、参照すべきdocsや本の紹介などを行い、勉強会を終えました。

その際の資料を外向けに改良したもの: Terraform入門資料(v0.12.0対応) ~基本知識から設計や運用、知っておくべきtipsまで~ - Qiita

この会を開くことによって、チーム内/社内だけにとどまらずグループ会社全体にIaCへの認識を浸透させられたのはとても大きかったと思います。(今自分がやっていることに対して理解をしてもらえ、背中を押してもらえるようになった)

これからも継続して、こういった会社間で開かれた勉強会を開催したり、他の人を巻き込んで一緒にやっていきたいと思っています。

3. Developer Productivityの向上

3.1 CI/CDの構築

なるべく早期に入れてやれると、チームで管理更新が非常に楽になる
- 各々のローカルでのデプロイは、操作履歴が終えないので非常にリスキー
「Infrastructure as Codeは、ソフトウェア開発のプラクティスをインフラのオートメーションに生かすアプローチ」なので、ここの仕組み化がIaCのわかりやすい恩恵
今回はCI/CDともにCodebuildで構築、ソースリポジトリはBitbucket
- CIではfmtチェック。今後tfupdateも組み込む予定
- CDはよくあるプルリク作成/変更でplanのタスクをCodebuildで実行、マージでapplyのタスク実行
plan/apply結果の通知は、tfnotifyを使用して、Slackに流している(本当は、bitbucketのプルリクコメントに流したい)

この構築の際、tfnotifyは一部分Bitbucketからの連携を考慮に入れていない作りだったので、プルリクを送って修正いただきました -> fix codebuild-ci code to allow sourceVersion not to has prefix "pr/" by fukubaka0825 · Pull Request #51 · mercari/tfnotify · GitHub

また、tfnotifyのnotifierにBitbucketは含まれていないため、対応してもらうプルリクを送ろうと作成していましたが、なかなかBitbucket APIのGoクライアントで使えるものがなく、そこから自分で作るしかないなぁと思っているステータスで止まっています。。(頑張りたい)

皆さんGithubなら最近はGithub Actionsで簡単にCI/CD構築できるっぽいのでそちらをご活用いただくと良いと思います。 -> 参考記事: GitHub Actionsで Terraformをplan&applyしてみた / I tried to plan and apply Terraform with GitHub Actions - Speaker Deck

これからの展望

IaC

IaCに関しては、現在ステージング・開発環境リソースのIaC化に着手しており、そちらはもうそろそろ落ち着きそうです。
これが終わり次第、本番環境のIaCを全てのdeveloperに対してタスクを振り分け、そこらへんはマネージしたりサポートしながら遂行して行こうと思っております。(タスクをこなすのが、一番早くスキルが身につく)
まだまだ道半ばなため、これからも継続して浸透させていく施策をどんどん打っていきます。
また、US/グローバル対応の際はかなり様々な知見が得られると思いますので、そちらの社内外にシェアしていきたいと考えております。

その他SRE全般

今年9月から、SRE NEXTの運営させていただいており、優秀なSREエンジニアに日々刺激を受けています。こういったコミュニティで吸収した知識もどんどんプロダクトにfeedback出来たらなと考えています。(monitoring、release engineering、SLI/SLOの最適化etc)

ただ、もちろん自分はいち開発者であり、そこに全てのリソースが避けるわけではないので、引き続きUS展開を中心にプロダクトの設計/実装もどんどんやっていきたいと思います。(開発者としての目線、スキルも養っていくことで運用をデザインしていく力も向上させていけると思っている。)

最後に

SREじゃないやつの記事で申し訳ありませんが、SREの思想はSREのためだけではないというのが僕の考えなので、そこらへんを感じていただけたなら幸いです。（implements devopsしていってるのでSREっぽいこともしている感じ）
これからも、アーリーな時期でのSRE/devopsとの向き合い方・タネの蒔き方を諸々チャレンジし、紹介できればと思っています。

アーリーなプロダクトのチームに対して、IaCの文化を浸透させるためにやっている３つのこと