徳永駿太

【サービス】 BtoB向けの不動産売買サービス 上記サービスのインフラのリニューアル前は、AWSのEC2インスタンスにapi用、メール送信用、定期的なバッチ処理用などの複数のdockerコンテナが起動している形での運用 【課題】 従来のEC2インスタンスに複数のコンテナを起動する構成では以下の課題があった 1. 今後のユーザー増加を想定した処理の分散化のために、より容易にコンテナの数を調整できる構成に変更したい 2. 従来のインフラ構成においてはTerraformでのコード管理はあったものの、EC2内のdockerコンテナ周りや急ぎでAWSのコンソールで作成したリソースが管理されておらず、詳細については作成者しかわからない状態だった 3. 本番環境でのログ管理が未完成だったため本番環境でバグが発生した時に、本番インフラへのアクセス権がないエンジニアがバグの原因把握ができない場面があった 【 行なった取り組み】 1に対しての取り組み: EC2での複数コンテナ起動を行っていた状態から、ECSでのクラスター管理に切り替えることでコンテナの起動をよりスケーラブルに対応できるようにした 2に対しての取り組み: ECS構成への切り替えと並行して、 - コード管理されていなかったAWSのリソースを洗い出して新たに記述 - dockerコンテナの設定をECSのタスク定義に一新して記述 3に対しての取り組み: ログの実装ができていない処理を洗い出し、新たにCloudWatchLogsでの出力を行なって、履歴をS3に残せるようにした を行なった 【 担当】 バックエンドとインフラを担当 【主な使用技術】 - Python - pyramid - Docker - AWS - AWS VPC - AWS EC2 - AWS ECS - AWS S3 - AWS Elasticache - AWS ALB - AWS Route53 - AWS Cloud Watch Logs - AWS CloudFront - Terraform - GitLab CI 【成果】 - タスク管理によって、コンテナの増減が容易になった - AWSのコンソール場でコンテナの稼働状態をすぐに把握できるようになった - 新しくジョインしたエンジニアでも、コードベースでインフラの構築状態を理解できるようになった - 本番インフラにアクセスできないエンジニアでもバグの把握が即時にできるようになった