Zenn
⚡

新生インフラ・SREチームの取り組み

2022/10/24に公開
AWS
CircleCI
#
SRE
tech

こんにちは。
株式会社ココナラのシステムプラットフォーム部でインフラ・SREチームのチームマネージャーをしているよしたくと申します。

本記事では2022/02より立ち上がったインフラ・SREチームの歩みと取り組んできた施策を紹介します。

チームの立ち上がり

以前のチーム状態

弊社では概ね1~2ヶ月に1回程度で大型のプロダクトリリースが行われます。当然大型リリースとなると

  • リリース内容に伴うサーバ等のインフラ設定修正
  • （必要であれば）サービスメンテナンス準備
  • リリース手順書の作成
  • リリース後のモニタリング

等々のインフラ作業が発生します。加えて小さなプロダクト改善も日々行っており、それに関連してインフラチームが作業する必要のあるものが多数存在します。
こういった環境下でインフラチームはというと、マネージャー含め最大3名という小さなチームでした。そのためメンバーは日々のプロダクト開発改善に関連するインフラ作業に追われ、直接的なプロダクト改善にはならない、インフラ施策や技術負債の解消へ工数を割くことが出来ていませんでした。

いわゆる「緊急ではないが重要なこと」へのコストを払うことが出来ない、そしてメンバーにも疲弊がみられるようになり、会社としても見直しが必要ということで新しいチーム体制が発足します。

ここがやりたい！

チーム構成

2022年1月〜4月にかけて多くのメンバーが入社し、現在のインフラ・SREチームが結成されました。
10月時点では、6名のメンバーで構成されています。入社1年未満のメンバーばかりのフレッシュなチームです！

チーム構成

チーム結成当初

主務メンバーは全員新しく入社したメンバーであり、既存メンバーの離脱もほぼ同時期に重なってしまったため、立ち上がりは苦労が多くありました。とくに苦労したのはチーム内でのコミュニケーションの図り方です。バックグラウンド（エンジニア歴・経験・得意分野）が異なることでお互いを探り合うような形となってしまい、ミーティングを行っても決まったようで実際アクションプランまでは定まっていないということが多々ありました。
この課題に対しては以下のような対応をとることでスムーズなミーティングの進行、議論の活発化へとつなげました。

  • 明確な役割を割り当てる
    • 統括をする人
    • その補佐をする人
    • 技術観点で実際の課題対応へのアプローチを考える人
  • 課題に対する考え方を整理
    • いわゆる緊急度×重要度マトリクス

意外と大切だと思ったこと

いまとなっては誰がどんな領域に得意/不得意、やりたい/やりたくないがあるかそれぞれの人となりをメンバーどうしでおおよそ把握できていると感じています。
その過程で私が大切だと思ったことが何気ない雑談の時間です。月日が経てば当然そうなるものかもしれませんが、雑談には次のような効果があると感じました。

  1. 仕事にかかわる話
  • 新しい観点からの気付き
  • 悩みや不満を吐き出すことができる
  1. 仕事以外の話（趣味、ウチでやっていること、ハマっていること）
  • 普段の考え方がわかる
  • なにかをお願いするときなど心理的なハードルが下がる

余談ですが、週に2回の出社日は基本的にチームみんなでランチに行くようにしています。ライス・ナン食べ放題のインドカレー屋さん🍛🫓が行きつけです！

チームの取り組み

ここからは新チームで取り組んできた施策について簡単に説明します。

朝会/日次モニタリング

メンバーごとにアサインされているタスクが異なるため、密なコミュニケーションを取ることが必要となり、取り組んでいることの共有や抱えている課題解決を目的とした朝会を日次で実施しています。
また、あわせてSRE活動の一環として日次モニタリングを実施することとしました。問題が発生した場合、アラートが発報されるように設定はしていますが、長期的な問題（たとえばサーバのメモリ使用量に継続的な増加傾向があるか）を検知することと、モニタリングできている項目とできていない項目を整理することが目的です。
サービスごとに分けていたダッシュボードはこのタイミングで見るべき項目を整理し、1つのダッシュボード（キャプチャは一部）にまとめて効率的なモニタリングを行うように工夫しています。

DDダッシュボード

クラウドリソースのメンテナンス

この半年はAWSリソースのメンテナンスを多く実施しました。リソースを作成した時期的にメンテナンスが多くなる周期だったかもしれません。

  1. EC2リタイアメント
  2. ElastiCacheリプレース
  3. RDB HWメンテナンス
  4. RDSマイナーアップグレード

以下の2つの理由からとくに「2. ElastiCacheリプレース」が大変でした。

  • メンテナンス通知はすべてAWS Health DashBoardに来ると思いこんでいたが、ElastiCacheは通知対象外であり検知できていなかった
    • → 緊急でサービスメンテナンスをいれる必要が出てきた
  • 作業完了したと思ったら1週間後にまた同サーバのメンテナンスが必須という通知を受け取った
    • → AWS側基盤のサーバ配置問題にハマった

1点目のようにAWS Health DashBoardにて変更内容を検知・確認されている事例は多くあると思いますが、AWS Health DashBoardでは検知できないメンテナンス通知もあることは要注意です。ElastiCacheの変更通知は下記のようにメールでは全イベントを検知し、うちとくに必要なものだけがSlackへ通知されるような仕組みを導入しました。

通知の仕組み

ナレッジのドキュメント化

前述のとおり、概ね1~2ヶ月に1回程度で大型のプロダクトリリースが行われ、必要に応じて準備を実施する必要があります。しかし、これまでの作業者がドキュメントを残す工数がなく、新規メンバーにとっては何が必要なのか不明瞭な状態でした。
そこでチームの誰でも取り組むことができるようにインフラ・SREチームリリース作業手順のドキュメントテンプレート化を行いました。具体的には以下のようなことを整理し、あわせて手動で行っていた作業の自動化に取り組みました。

  • サービスメンテナンス時の基本的な作業の流れ
  • いつまでにどのような準備作業が必要であるか
  • 他チームの作業と連携が必要な点

また、サービスメンテナンスのように定期的な作業だけではなく、技術検証した内容やメンテナンスにむけて行った調査内容も可能な限りドキュメントに残していくということをチームの基本方針としています。実際にElastiCacheリプレース作業は時間をおいて複数回発生していて、初回対応時に対応したこと・調査したことの記録をドキュメントに残しておいたため、2回目の対応時に過去実績を追いやすく、自分たちが助かったということがありました。

CircleCI → AWSのOIDC化

2022/03末にCircleCIがOpenIDConnectのサポートを開始したことを受け、遅ればせながらCircleCIジョブでのaws認証形式をキーレスにしてみました。
具体的にはIDプロバイダとciごとに必要なIAMロールの作成をmodule化したterraformで適用し、CircleCI側では共通化したコマンドを呼び出して使用するようにしています。

module
resource "aws_iam_openid_connect_provider" "this" {
  url = "https://oidc.circleci.com/org/${var.circleci_org_id}"

  client_id_list  = [var.circleci_org_id]
  thumbprint_list = [var.circleci_thumbprint]
}

resource "aws_iam_role" "this" {
  name               = "application-deploy-circleci"
  assume_role_policy = data.aws_iam_policy_document.this.json

  tags = {
    Name = "application-deploy-circleci"
  }
}

data "aws_iam_policy_document" "this" {
  statement {
    actions = [
      "sts:AssumeRoleWithWebIdentity",
    ]

    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.this.arn]
    }

    condition {
      test     = "StringLike"
      variable = "oidc.circleci.com/org/${var.circleci_org_id}:sub"
      values   = ["org/${var.circleci_org_id}/project/${var.circleci_pj_id}/user/*"]
    }
  }
}

resource "aws_iam_role_policy_attachment" "this" {
  for_each = var.ci_roles

  role       = aws_iam_role.this.name
  policy_arn = each.key
}

output "arn_aws_iam_role_this" {
  value = aws_iam_role.this.arn
}
config.yml
commands:
  setup-aws:
    steps:
      - run:
          name: install jq
          command: sudo apt update && sudo apt install -y jq
      - aws-cli/install
      - run:
          name: oidc authentication
          command: |
            aws_sts_credentials=$(aws sts assume-role-with-web-identity \
              --role-arn ${AWS_ROLE_ARN} \
              --web-identity-token ${CIRCLE_OIDC_TOKEN} \
              --role-session-name "circleci-oidc" \
              --duration-seconds 900 \
              --query "Credentials" \
              --output "json")
            echo export AWS_ACCESS_KEY_ID="$(echo $aws_sts_credentials | jq -r '.AccessKeyId')" >> $BASH_ENV
            echo export AWS_SECRET_ACCESS_KEY="$(echo $aws_sts_credentials | jq -r '.SecretAccessKey')" >> $BASH_ENV
            echo export AWS_SESSION_TOKEN="$(echo $aws_sts_credentials | jq -r '.SessionToken')" >> $BASH_ENV
            source $BASH_ENV

deploy-prod:
    executor: deployer
    steps:
      - checkout
      - setup-aws
      - deploy_ec2:
          environment: prod

すべてのリポジトリで実践できているわけではないので、今後順次展開していく予定です。

おわりに

インフラ・SREチームの歩みと取り組んできた施策の一部をご紹介しました。個人としてもチームとしても大きく成長できた半年間だったと感じています。
今後急拡大していくココナラを、より安定的により堅固に運用していけるよう邁進していきます。

SRE求人はこちら

https://open.talentio.com/r/1/c/coconala/pages/49719

ブログの内容への感想、カジュアルにココナラの技術組織の話をしてみたい方はこちら

https://open.talentio.com/r/1/c/coconala/pages/70417
　※ブログ閲覧者の方限定のカジュアル面談の応募フォームとなります！

エンジニアの募集職種一覧はこちら

https://coconala.co.jp/recruit/engineer

まだまだインフラ・SREチームとしてやりたいことがたくさんあります。一例としてサービスのスケールに向けてRDSのAurora移行・Kubernetes導入や、分析のためのDBデータ→BigQueryリアルタイム化などの推進を検討しています。
ご興味ある方はぜひぜひご応募ください！

Discussion