はじめまして、Spartyインフラエンジニアの「おだ」です。
技術記事1本目に何を書こうかと悩んでいたのですが、インフラエンジニアらしくSpartyが手掛けるサービスのインフラ周りについて書きたいと思います。
さっそく手前味噌になりますが、2022年1月から弊社製品のTVCMが放映されていました。
sparty.jp
10月に入社をしたのですが、キャッチアップをしているときに唐突にTVCMをやるという話が聞こえてきました・・・
入社後すぐに重たい対応できるのか？と思いつつ環境の理解も進み、案の定負荷に耐えられそうにない構成だったため、このタイミングで放映の負荷に耐えられるようなインフラ構成に変えるべく、リプレイスを始めました。
１．TVCM放映前の構成について
構成は一般的なweb/cache/databaseの3層構造になっていましたが、特にwebレイヤーに問題を抱えていました。
webレイヤーでサーバ1台でしかリクエストを捌いておらず、スケールアウトしようにも都度手作業での構築が必要になりオートスケールもなく、急なリクエスト増加には耐えきれない状態でした。
リプレイスが始まるよりも前にコンテナ化の希望があり、開発環境はコンテナ化されていたため、このタイミングで本番環境でのコンテナ運用を決めました。
また、以下の理由によりkubernetesの採用も決めました。
- 海外展開等のワードが社内で聞こえてきたため、システムの抽象度を上げポータビリティを確保したい
- インフラ専任者が一人のため、インフラの見える化、Infrastructure as Codeを押し進め、他エンジニアでもキャッチアップ＆フォローが行いやすい状態にしたい
- kubernetesの運用経験を持つエンジニアが在籍している
２．インフラ環境のコード化
開発環境用のansibleの他にもterraformが用意されていましたが、記述バージョンも古く一部コード化されていない部分があったため、最初から組み直すことにしました。
組み直してからも、あーでもないこーでもない。と繰り返し設計し直して、以下のようなコード構成となりました。※一部情報は削っています。
> ディレクトリ構成を展開する
% tree ./terraform ├── modules │ └── aws │ ├── acm │ ├── backup │ ├── cloudtrail │ ├── cloudwatch │ ├── codecommit │ ├── codedeploy │ ├── codepipeline │ ├── cognito │ ├── ec2 │ ├── ecr │ ├── ecs │ ├── eks │ ├── elasticache │ ├── elasticsearch │ ├── lb │ ├── rds │ ├── redshift │ ├── route53 │ ├── s3 │ ├── s3_ignore_changes_grant │ ├── security_group │ ├── ses │ ├── terraform_state_s3 │ └── vpc ├── iam │ └── users │ ├── iam_group.tf │ ├── iam_user.tf │ └── variables.tf ├── cloudfront │ ├── cloudfront.tf │ ├── datasource-acm.tf │ ├── datasource-route53.tf │ ├── datasource-s3.tf │ ├── envs │ │ ├── dev │ │ │ ├── main.tf │ │ │ └── variables.tf │ │ └── prod │ │ ├── main.tf │ │ └── variables.tf │ ├── s3-logging-cf.tf │ └── variables.tf ├── db │ ├── datasoure.tf │ ├── db-cluster.tf │ ├── db-instance.tf │ ├── elasticache.tf │ ├── envs │ │ ├── dev │ │ │ ├── main.tf │ │ │ └── variables.tf │ │ └── prod │ │ ├── main.tf │ │ └── variables.tf │ ├── securty-group.tf │ └── variables.tf └── eks ├── eks-iam-role.tf ├── eks-serviceaccount.tf ├── eks-cluster.tf ├── envs │ ├── dev │ │ ├── main.tf │ │ ├── output.tf │ │ └── variables.tf │ └── prod │ ├── main.tf │ ├── output.tf │ └── variables.tf ├── output.tf ├── s3.tf ├── securty-group.tf ├── variables.tf ├── vpc.tf └── waf.tf
初期構成では１つのプロジェクトに全てが収まっていましたが、規模が大きくなるにつれplanの量が増えてしまい、結果を得るまでに時間を要してしまうため、分割できる単位で切り分けました。
３．いざ、リプレイス
Cloudfrontがいるため、オリジンの向き先をkubernetesで立てたingress宛へ変更して、トラフィックをリプレイス環境へ切り替えました。
リプレイス後の構成が以下の図です。
コンテナ化、さらにはkubernetesの導入で非常に簡単にオートスケールを実現できるようになりました。
kubernetesはEKSを利用していますが、EC2ベースで構築しているためClusterAutoScalerも導入されています。
これにより、無事TVCM放映による負荷にも耐え、放映期間中にサーバが落ちるというような障害は起きませんでした。
TVCMが流れる度にコンテナのオートスケールが動き、ただちにコンテナが増えていく様子は見ていて気持ちよかったです。
最後に、、、
TVCM放映の対応に間に合わせるべく急激に環境のモダン化を進めたのは良かったものの、学習コストが増えたこともあり、全エンジニアメンバーが新環境に関してキャッチアップできておりません。
今後は、全メンバーがkubernetes上で自由に開発できるよう環境整備を整えつつ、全員が現行の環境にキャッチアップできるよう取り組んでいけたらと思っております。
