チームSRE立ち上げ期にやってみて良かったこと

こんにちは、エムスリーエンジニアリンググループ / 製薬企業向けプラットフォームチームの鳥山 (@to_lz1)です。

この記事はエムスリーSREがお届けするブログリレーの8日目です。

このブログリレーで複数回言及されているように、エムスリーでは昨年から大々的に「チームSRE」という制度を導入しています。従来からのSREすなわち「コアSRE」が受け持っていた業務や権限を、各プロダクトチーム内のSREすなわち「チームSRE」に委譲している真っ最中です。

私の所属する製薬企業向けプラットフォームチーム（Unit1と呼ばれています）のチームSREの導入タイムラインは、以下のような感じです。

2020年4月に最初のチームSREが入社
2020年7月ごろに私を含む6名がチームSREとして追加
複数サービスのクラウド移行を実施しつつ今に至る

したがって、少なくとも私のチームではこの「チームSRE」という取り組みは始まって1年足らず、まだまだ立ち上げ期と呼んで良いかと思います。

今回は、そんなフェーズの中でチームSREとしてやってみたこと、やって良かったと感じたことをいくつかご紹介します。

1. Terraformリポジトリの一元化
2. 移行作業の「Zoom中継」
- 中継して起きた素敵なこと
まとめ: コロナ禍でも「コラボレーション」を諦めない
We are Hiring!

f:id:to_lz1:20210121002103j:plain — 何かを立ち上げるには大規模な工事が必要になる...ときもあります

1. Terraformリポジトリの一元化

「開発を本格的に進めよう！」というとき、「リポジトリとディレクトリの構成どうする？」というのはほぼ必ず付きまとってくる問いかと思います。

2020年7月ごろのUnit1のクラウド化状況を「Terraformのリポジトリ」という観点で振り返ってみると、

サービスごとに xxx(サービス名)-infra リポジトリがあり、その中に .tfファイルを置いている
そうしたリポジトリが2つ, 3つある

という状況でした。このままサービスごとにリポジトリを増やしていく手もあったのですが、少し煩雑になるかなと考えて7月の段階でUnit1のTerraform関連資材を統一するリポジトリを作ることにしました。リポジトリ間で重複・衝突するリソースを作ってしまうリスクを軽減したい、というのも当初の目的の1つでした。

構成そのものをどう作ったか、という点については弊社の福林(@fukubaya)によるこちらの記事が大変詳しいです。チームが別なのでリポジトリも別なのですが、結局ほとんど同じ構成に落ち着きました。

# 構成のイメージ
unit1-infra
├── service1
│   ├── 本番環境のtfstate
│   └── 検証環境のtfsfate
├── service2
│   ├── 本番環境のtfstate
│   └── 検証環境のtfsfate
├── service3
│   ├── 本番環境のtfstate
│   └── 検証環境のtfsfate
...

統一して起きた素敵なこと

このタイミングでリポジトリを統一したことで、以下に挙げるようなメリットが得られました。

CIの共通化

TerraformをどうCIしていくか、というのもまた正解のない難しい問いなのですが、Unit1では概ね以下のようなフローにしました。

変更があれば全環境の terraform plan を行う
マージされると検証環境には自動で terraform apply される
本番applyだけはチームSREが手動でJobをkickする

また、処理結果はメルカリ社が公開するOSSである tfnotify を利用して通知しています。

github.com

gitlab-ci.yml は例えば以下のようになります。

stages:
  - fmt
  - plan
  - apply

fmt:
  stage: fmt
  script:
    - terraform fmt -recursive -diff=true -check=true

.qa-common: &qa-common
  before_script:
    - apk add --upgrade curl
    - curl -fL -o /tmp/tfnotify.tar.gz https://github.com/mercari/tfnotify/releases/download/v0.7.0/tfnotify_linux_amd64.tar.gz
    - tar -C /usr/bin -xzf /tmp/tfnotify.tar.gz
    # Set AWS Account Credentials
    - export AWS_ACCOUNT=${AWS_ACCOUNT_QA}
    - export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID_QA}
    - export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY_QA}

.plan-common: &plan-common
  stage: plan
  script:
    - cd ${TF_PROJECT_DIR}
    - sed -i -e "s/\$COMPONENT/${COMPONENT}/" ${CI_PROJECT_DIR}/.tfnotify.yml
    - terraform init
    - terraform plan | tfnotify --config ${CI_PROJECT_DIR}/.tfnotify.yml plan

# &prod-common と &apply-common は省略

plan_qa_service1:
  variables:
    TF_PROJECT_DIR: "service1/qa"
    COMPONENT: service1_qa
  <<: *qa-common
  <<: *plan-common
  only:
    changes:
      - service1/qa/**/*
      - service1/shared/**/*

anchor部分の記述が多いですが、こうしておくと便利なのが「サービスが増えても非常に少ない記述量でCIの設定が完了する」ことです。まだ改善余地はあるかと思いますが、考えること少なくCIのフローを構築できるようになったのはチームとして非常に良かったと思います。

「ちょっとしたソリューション」を試しやすい

この施策のためにこのサービスを試してみたい...
ある程度共通的に使い回せるAWS Route53 Hosted Zoneを作りたい...

こういうアイデア、よく浮かんでくると思います。というかチーム内で浮かんで来ました。この場合、チームで統一したリポジトリがあると最小の手数でインフラ構築・検証に着手できて便利です。レビューする側としても「いつものリポジトリ」を観に行けば良いので無理なくコードレビューを回すことができます。

こうしたメリットを享受できたことも、統一したリポジトリを作って良かった点の1つかなと思います。

リポジトリの作成からはわずか半年ほどですが、2021-01-22現在 unit1-infra リポジトリは実に10サービス分のディレクトリを持ち、更にそれぞれの配下に複数環境のWorking Directoryがある...、という状態にまで成長してきました。Terraformはもともと全社に普及していたとはいえ、チーム内での事例は昨夏を振り返るとかなり少なかったので、自分でも驚くようなスピードでクラウド化が進んだなと思っています。

2. 移行作業の「Zoom中継」

さて、Unit1に最初のチームSREが入社した「2020年4月」というのはコロナ禍が我々の就業環境に影響を与え始めた正にその時期です。エムスリーでもすっかりリモートでの勤務がおなじみとなりました*1。

そんな中、立ち上げたばかりのチームSREを中心にどうやってクラウド化を進めていくのか、というのは完全に未知の課題でした。様々な議論・困難があったのですが、ここでは「移行作業当日」をどう過ごしたのか、という1つの事例を共有したいと思います。

切っ掛けはあるマイクロサービスのDB移行作業をどう実施するか、という話をした時のことです。要件としては、以下のようなものでした:

オンプレミス仮想環境のPostgreSQLをAWS Auroraに移行する
移行作業にはPostgreSQL標準のユーティリティ pg_dump を用いる
サービスは止めない。DB移行とコンテナの接続先切り替え(Rolling Update)を順次行う
Rolling Update中に旧DBにinsertされたデータは後から書き戻す

チームSRE内にDB移行作業の経験者はいましたが、私も含め「DBをクラウドに移行する実作業」を経験したメンバーはいませんでした。そこで少しでもリスクを減らすために「移行当日はチームSRE複数名で私のZoomに集まってもらって、そこで作業をしましょう」ということになりました。

中継して起きた素敵なこと

まず人が集まる中で作業に手間取ると気まずい（し、効率的でない）ので、手順書は入念にConfluenceに記載しました。これだけでもメリットと言えますが、実際に作業が始まると、

筆者「あ、この作業、私の権限+本番環境だと通らないですね...」

同僚Mさん「じゃあここは本番リハした私がやります！」

とか、

筆者「コンテナの切り替え進んでいるみたいです」

同僚Iさん「新しいDBにちゃんとデータ入ってきてますね」

同僚Gさん「ALBのメトリクス観てますがレスポンスタイムも大丈夫そうです」

など、その場での自然発生的な協力が次々に発生したのです。特に事前に役割を決めたりしたわけではなかったので、これは嬉しい驚きでした。想定外の事象もあったものの、結果としては非常に大きな安心感を持ってインフラ作業を完遂できました。

作業の"中継"に関して、最初は「まあ知見の共有になるかな」程度の思いだったのですが、後から振り返ってみると「実は高いチームパフォーマンスを発揮するために割と良い取り組みなのでは？」という仮説を持つに至りました。

働き方が変わっていく中で、チームでできる取り組みはまだまだ考えたいし、知見もどんどん共有したいなと思う今日この頃です。チームの共同を促進する手段としての「作業中継」、いかがでしょうか。

まとめ: コロナ禍でも「コラボレーション」を諦めない

本稿では、チームSRE立ち上げ期の取り組みを2つご紹介しました。少し毛色の異なる話題ではあったものの、突き詰めると両方とも「コラボレーションを促進する」ことに繋がっていたな、などと思って今回1つの記事にまとめてみることにしました。

"Observable Work"（作業の可視化）と"Narrating Your Work"（作業の共有）の組み合わせがコラボレーションによる成果の達成を促す、という考え方もあります*2。私自身日常的に意識するようなレベルにはまだまだ達していないのですが、チーム開発を日々実践する上で大事にしたいアイデアの1つです。

リモート勤務が増える今だからこそ、どうやって作業を可視化し、共有し、成果を出していくのかということを改めて考えることには意味がある。チームSREとしてやってきたことを振り返って、そんな思いを抱いた次第です。