moritakee

## プロジェクトの目的・背景 - EC2ベースの従来インフラにおける以下の課題解決 - インフラ管理の属人化（IaC未導入） - デプロイ・マイグレーションの属人化 - 可用性 - セキュリティ・コスト最適化の不足 - インフラのモダン化（コンテナ化）要望への対応 ## プロジェクト規模・体制 - 4~5名の副業エンジニアで構成されるチームに専任インフラエンジニアとして途中参画 ## 担当業務・役割 - インフラリプレイスの設計・実装の主担当 - AWSインフラのIaC化 - CI/CDパイプラインの構築 - セキュリティ強化 - コスト最適化 - インフラドキュメントの整備と共有 ## 使用技術 - AWS(CloudFront・WAF・ALB・ECS/Fargate・RDS・SecurityHub・GuardDuty) - GitHub Actions ## 課題 開発当初は専任のインフラエンジニアが居なかったため、バックエンドエンジニアの開発メンバーの方がEC2ベースでインフラを構築されていました。 しかし、以下の点が問題となっておりこれらを改善するためにプロジェクトに参画しました。 - インフラ周りが適切に管理できていない(IaCなどが使われていない) - デプロイ作業の属人化 - 可用性が担保されていないこと - セキュリティやコスト最適化がされていないこと また、プロジェクトオーナーの方から後々のことを考えてコンテナ化などインフラをモダンにしてほしいとの要望もありました。 ## 具体的な取り組み 上記の課題に対して以下の取り組みを行いました。 1. インフラのモダン化 - バックエンドをEC2からECS/Fargateに移行 - フロントエンドをAppRunnerからECS/Fargateに移行 - コンテナスペックやスケーリング設定など - 踏み台サーバのコスト低減 2. 手動作業・属人化の排除 - GitHub Actionsを使ったデプロイフローの整備 - Notionを使いインフラ周りのドキュメント整備 3. セキュリティ対応 - GuardDutyやSecurityHubを設定・対応 ## 工夫した点 1. 技術選定 AWSインフラのリプレイスを行うにあたり、ECS/FargateおよびAppRunnerのどちらを使うか技術検証を行いました。 私自身AppRunnerの利用経験がないこととAppRunnerの本番利用の事例をあまり聞いたことがなかったため、リプレイスにあたり機能要件・非機能要件を満たせるか検証を行いました。 結果として、以下の理由によりAppRunnerは採用せずECS/Fargateを利用することに決めました。 - 一部AppRunnerのリソースがTerraform管理できない - ネットワーク周りのリソースの更新ができない(削除→再作成となる) - デプロイが遅い(内部でB/Gデプロイが行われているため) - オートスケーリングの指標が限られている(リクエスト数のみ) 2. Terraformを使ったIaC化 既存のAWSリソースは全てIaC管理されていなかったため、リプレイスにあたり全てをTerraform管理するようにしました。Terraformに詳しい開発メンバーがいなかったため、なるべく複雑性を下げるためmoduleは使用しないようにしました。また、コード品質の担保とセキュリティ・ガバナンスの観点からTerraformのCI/CDをGitHub Actionsで実装し開発メンバーでも簡単にPRを出せるようにドキュメントを整備しました。 - PR作成時のCI - plan実行して結果をPRにコメント - tflint・trivyの実行 - PRマージ時のCD - apply実行して結果をPRにコメント 3. コスト最適化の実現 コスト削減のため、踏み台コンテナを常時起動するのではなく開発メンバーが必要なタイミングで起動できるような構成を作りました。 工夫した内容としては、 - Slackから踏み台コンテナを起動 - AWS Chatbotを使って踏み台コンテナを起動させることで誰がいつ踏み台を起動したかを記録できるようにしました - 作業終了時に自動でコンテナを落とす - コンテナのエントリーポイントとして、10分おきにコンテナ内にSSMで接続しているユーザ数をチェックし接続ユーザがいなければプロセスが落ちるようにしました ## 得られた知見・教訓 1. DevOpsとDX向上 - IaCとCI/CD整備により、開発者が安全かつ効率的にインフラ操作可能に - ドキュメント整備による知見共有の重要性 2. 技術選定の重要性 - 新技術（AppRunner）の検証による適切な判断 - チーム全体の技術レベルを考慮した実装方針決定 3. コスト最適化とユーザビリティの両立 - Slack連携による使いやすさの実現 - 自動化による運用コスト削減 4. チーム全体の生産性向上 - インフラ操作の民主化 - 属人化の解消 - 自動化による作業効率の向上

## プロジェクトの目的・背景 自社で使用しているAWS・CircleCI・Datadogのコスト削減や利用推進を行いました。 - 各種クラウドサービスのコスト増大への対応 - Datadogの活用度向上とコストパフォーマンス改善 - 開発者の効率的なツール活用の促進 ## プロジェクト規模・体制 - インフラSREチームの1メンバーとして対応 ## 担当業務・役割 - AWS運用コストの最適化 - CircleCIのパフォーマンス改善 - Datadogの活用促進・コスト管理 - 開発チームへの技術共有 ## 使用技術 - AWS(ECS/Fargate・NATGW・VPCエンドポイント) - Datadog - CircleCI ## 具体的な取り組み 1. ECS/Fargateのコスト削減 自社では各サービスの実行基盤をEC2からECS Fargateに移行済みでしたが、EC2時代に比較するとコストが高くなってしまうので、コスト削減のためにFargate Spotの導入を行いました。 基本的には、サービスのトラフィックに応じて最低台数はFargateで起動するようにし、オートスケールで起動するコンテナの一部をFargate Spotで起動するように設定しました。 これにより、ECS・Fargateのコストを40%削減することができました。 2. NATGWのコスト削減 Webアプリケーションではサイドカーとしてdatadog-agentを使っていました。 ECSタスクを起動する際に、datadog-agentのコンテナイメージをNATGWを経由してpullするようになっており、ECSタスクの起動回数が増えるごとにNATGWの通信量が増大していました。 これを回避するために、datadog-agentのコンテナイメージをECRプルスルーキャッシュを使いNATGWではなくECRに対してVPCエンドポイントを経由してイメージをpullするように設定しました。 これによりNATGWの通信コストを60%程度削減しました。 3. CircleCIの改善 CircleCIでは以下の問題があり、これを修正することでコスト削減とコンテナビルドの高速化を行いました。 - CIの最適化 - アプリケーションコードに変更があった場合のみテストを実行するように変更し、無駄なCIが走らないようにしました - 使用するVM・コンテナのresource_classの最適化 - CPUを使わないようなジョブはresource_classをsmallにしてコストを抑えるようにしました。また、使用していた一部のCircleCI Orbsはresource_classのパラメータがなかったので、[PR](https://github.com/CircleCI-Public/terraform-orb/pull/69)を出したりしました - コンテナイメージのビルド最適化 - CircleCIのDLCはうまく使われないことがあるのと消費クレジットが大きいので、`--cache-from`と`--cache-to`を使い、キャッシュ用のイメージをECRに置いて使うことでコンテナビルドの高速化とコスト最適化を行いました 4. Datadogの改善 Datadogの課金体系や課金状況を正しく把握しているメンバーがいない状態となっていました。 また、Datadogを導入したもののAPMやログなど開発者に効果的に使用してもらえるように布教活動ができておらず、コストパフォーマンスがあまり良くない状態となっていました。 上記を改善するために、コスト最適化と開発チームに対してのDatadogの利用促進として以下を行いました。 - Datadogの課金体系・課金状況の調査とチームへの共有 - 無駄なコストの削減 - データ取得不要なEC2の棚卸しや取得対象からの除外、Fargate task数やAPM・Log周りのcommited costの最適化を行いました。 - Cloudwatch metrics streamの設定 - 開発チームへAPMの見方・使い方の共有 上記を行うことで全体で月$700ほどのコストを削減することができました。 また、QAや開発チームのメンバーがDatadogを使いこなすための下地を作ることができました。 ## 定量的な成果 - ECS/Fargateコスト：40%削減 - NATGW通信コスト：60%削減 - Datadogコスト：月額$700削減