IU SREの藤本です。
IUとは株式会社CAM、株式会社タップルを含めたサイバーエージェントグループ7社からなる統括本部です。
今回はIUでSREとして内定者アルバイトに来ていた岡 麦(Twitter: @mugiokax)さんの成果レポートになります。
この記事を通して、CyberAgentでSREとして体験できるインターンや内定者アルバイトの雰囲気を感じていただけますと幸いです。
はじめに
期間 : 8/3 ~ 9/30
部署 : IU > 株式会社CAM/株式会社タップル > SRE
貸与PC：MacBookPro 16inch
トレーナー : 庭木(CAM)、神山(CAM)、赤野(タップル)、松岡(タップル)
今回はCAM、タップルでのSRE業務に従事してもらいました。
CAM、タップルともにAWS、GCP環境でサービスが動いています。
岡さんはGCP環境でのインフラ構築は得意なので、内定者アルバイト時の目標を「GCPでできる環境構築を、AWSでもできるようにする」とし、重点的にAWS環境での開発に取り組んでもらいました。
やったこと
CAM
インフラ構築
使用技術
- Amazon ECS
- AWS CodeBuild
- AWS CodeDeploy
- AWS CodePipeline
新規サービスのインフラを構築する必要があり、CAMの多くのサービスで利用されている以下のAWSサービスで構築してもらいました。
コンテナオーケストレーションサービス
・ECS
CI/CD環境
・CodeBuild
・CodeDeploy
・CodePipeline
CAMではIaCとしてCloudFormationを用いており、そのyamlも1から書いて、開発、ステージング、本番環境でリソースを作成してもらいました。
ここでの大きな成果はCAMではまだ未採用だったCodeDeployによるBlue/Green デプロイをCodePipelineで実装したことです。
Blue/Green デプロイは通常のローリングアップデートとは違い、デプロイにより完全に新しい環境が作成され、古い環境へ向いていたトラフィックを新しい環境へ向けるデプロイ手法です。
これにより、デプロイにバグが含まれていた場合の旧環境への切り戻しが容易になり、安全なデプロイを行えます。
ecs.yaml
Resources: ECSService: Type: AWS::ECS::Service ~~ DeploymentController: Type: CODE_DEPLOY ~~
codeDeploy.yaml
Resources: Pipeline: Type: AWS::CodePipeline::Pipeline Properties: ~~ Stages: - Name: Deploy Actions: - Name: Deploy ActionTypeId: Category: Deploy Owner: AWS Version: 1 Provider: CodeDeployToECS Configuration: ApplicationName: xxx DeploymentGroupName: xxx Image1ArtifactName: xxx Image1ContainerName: xxx TaskDefinitionTemplateArtifact: xxx TaskDefinitionTemplatePath: xxx AppSpecTemplateArtifact: xxx AppSpecTemplatePath: xxx InputArtifacts: - Name: xxx RunOrder: 1
Cost Reporter の作成
使用技術
- AWS Lambda
- AWS Chatbot
CAMでは複数サービスから共通にリクエストされるAPIサーバーがあります。
今まではそのサーバー費用を、リクエストしているクライアントごとに計算をするために、CloudWatchメトリクスでリクエスト数を見て計算していました。
それを自動化するために、各クライアントごとに作られたCloudFrontディストリビューションのアクセス数を、slackに定期的に通知してくれる集計BotをLambdaで作成してもらいました。
これにより、手作業がなくなり、slackを見るだけで、費用分配数値がわかるようになりました。
SREの原則にもある「トイルの撲滅」を正に実行してくれました！
自動化するためにコードを書いて実行環境へのデプロイまで全て行ってもらい、SREらしいことが体験できたのではないでしょうか。
IAMPolicyManager の作成
使用技術
- Cloud Run
- Cloud Scheduler
- Cloud Resource Manager
- Cloud Storage
- Cloud Logging
CAMではGCP環境で動くサービスも多くあり、多くのIAMリソースが存在します。
そこでインシデント対策、セキュリティリスク排除のためにIAMPolicyの変更があったときに自動でslack通知するようなBotを作成してもらいました。
アーキテクチャは以下です。
1日1回、Cloud Scheduler で Cloud Run を定期実行します。
Cloud Run で CloudResource Manager のAPIを叩き、現状のIAMPolicy設定と過去の設定を比較し、変更があればslackに通知します。
IAMPolicy設定情報は見直せるように、CSV形式でGCSに保存しています。
これにより、SREが全権限付与を把握でき、適切でない権限がIAMへ付与されたことに気付けます。
タップル
Fargate Spotの導入
使用技術
- AWS Fargate Spot
- Amazon EventBridge
- Amazon SNS
- AWS Chatbot
- Terraform
タップルではアプリケーションの実行環境にECS Fargateを利用しており、コストカットを目的として開発環境にFargate Spotを実施しました。
実際には停止の挙動の調査、クラスタへの起動タイププロバイダーの追加とサービスの起動タイプ変更、停止のSlack通知を行いました。
最終的にFargate Spotを導入したことで、$500/月のコストカットに成功しました！
slack通知は以下のフローで行います。
EventBridge -> SNS -> Chatbot -> Slack
以下はEventBridge イベントルールです。
eventRule.json
{ "source": [ "aws.ecs" ], "detail-type": [ "ECS Task State Change" ], "detail": { "stoppedReason": [ "Your Spot Task was interrupted." ] } }
tfsec 導入
タップルではインフラリソース管理をterraformで実施しています。
IaC化したタイミングで、脆弱性のある設定になっていないかを検出するツールとしてtfsecを導入しました
使用技術
- tfsec
- GitHub Actions
技術選定
- vscodeに拡張機能がある
- 実行が迅速でCIに組み込みやすい
- セキュリティスキャンにネイティブ対応
- プルリクエストにコメントつけられる
以上のことが理由で、tfsecを導入しました。
プルリクエストに解析結果をコメントできない不具合があったため、公式リポジトリ(https://github.com/aquasecurity/tfsec-pr-commenter-action)にプルリクエストを出して、マージしてもらいました。
そのプルリクエストが以下です。
https://github.com/aquasecurity/tfsec-pr-commenter-action/pull/19
感想
以下、岡さんの感想です。
とにかく裁量が大きいと感じました。
実現したい要件の検証、設計段階から任せていただけたのでとても嬉しかったです。
内定者アルバイト期間の目標として「GCPでできる環境構築を、AWSでもできるようにする」というものを立てたのですが、AWSを使用した基本的なWeb三層構造の構築から、Codeシリーズを使用した少し特殊な要件の実現など幅広くAWSを学べたことで、目標は優にクリアし、自信を持って「AWSを使用したことがあります」と言えるようになりました。
要件定義につまづいた際の、壁打ちも親身になって聞いていただいたおかげで内定者アルバイト期間に行う予定だったタスクも完遂できてすごく満足しています。
学びあり、交流あり、楽しさありの最高の内定者アルバイトでした。
最後になりますが、内定者アルバイト期間中サポートしてくれたIU SREメンバーの皆さんを始め、人事の皆さん、ランチ会・懇親会を開いてくれた皆さん本当にありがとうございました。
サイバーエージェントに興味のあるエンジニア学生の方はぜひ採用ページをご確認ください。