ID:63383さん

## プロジェクト概要 エンタープライズ向けECプラットフォームの開発チームにおいて、急速な組織拡大（エンジニア数が約2倍）に伴いCI/CDが未整備のまま開発効率が低下していた。Bitbucketから GitHub への移行を主導しながら、GitHub Actions によるCI/CDパイプラインを設計・構築した。 ## 担当したこと - Bitbucket から GitHub へのリポジトリ移行を主導 - GitHub Actions による以下のパイプラインを設計・実装 - 自動テスト - テスト環境への自動デプロイ - プッシュ時のビルド・マイグレーションチェック - リポジトリにIP制限がある環境への対応として、AWS CodeBuild + NAT Gateway（固定IP）構成を設計 - CI/CD実行結果（開始 / 成功 / 失敗）の Slack 通知を実装し、チーム全体の可視性を向上 ## 工夫した点 GitHub Actions から IP 制限のある社内リポジトリへアクセスする必要があり、GitHub Actions のIPは動的で固定できないという問題があった。AWS CodeBuild を経由させることで固定IPを確保し、NAT Gateway と組み合わせて制限を回避する構成を設計・実装した。単に「動くCI」を作るだけでなく、Slack 通知によってエンジニアがPRを出した際に結果を能動的に追いかけなくてもよい体験を意識した。 ## 成果 - 開発・テスト・リリースの属人化を解消し、チーム拡大後も安定した開発フローを維持 - **年間概算 約1,500時間の工数削減**を達成 - 本施策が評価され、**社内1Qのプロジェクト賞（MVP）を受賞** ## 使用技術 GitHub Actions / GitHub / AWS CodeBuild / NAT Gateway / Slack / Bitbucket（移行元）

## プロジェクト概要 エンタープライズ向けECプラットフォームにおいて、フロント開発環境が複数の AWS アカウントに分散しており運用コストが肥大化していた。加えて、デバッグログの大量出力により CloudWatch Logs のコストも増加していた。インフラチームおよびテストチームと連携し、環境統合とログ設計の2軸からコスト削減を主導した。 ## 担当したこと **フロント開発環境の統合・標準化** - 複数の AWS アカウントに分散したフロント開発環境を単一アカウントへ統合 - config 直書き・個人PCビルドの属人化運用を廃止し、環境変数のみによる設定管理に統一 - GitHub Actions による自動デプロイを実装し、AWS 操作権限を持たないメンバーでも環境反映が可能な仕組みを構築 - 全 AWS アカウントを横断した未使用リソースの洗い出し・削除、ECS スペックの見直し、開発環境の停止スケジュール設定 **CloudWatch Logs コスト削減（ログ設計）** - AWS FireLens + fluent-bit を導入し、ログ出力先を用途別に分離 - ERROR / WARNING → CloudWatch Logs（監視用） - その他ログ → S3（保存用・低コスト） - 負荷試験にてコスト削減効果を検証し、本番展開の判断材料を確保 ## 工夫した点 単純なリソース削除にとどまらず、「誰でもデプロイできる環境」を目指した設計を意識した。各環境へのデプロイが担当者ごとに分断されていた問題を、GitHub Actions による自動デプロイと環境変数の一元管理で根本から解消した。ログ設計においては、全ログを一律 CloudWatch Logs に送るのではなく、監視に必要なログだけを残し他は S3 に流す分離設計を採用した。負荷試験で効果を事前検証し、本番展開の判断材料を確保した点もこだわった。 ## 成果 - **月額 約56万円のインフラコスト削減**を達成 - フロント環境をバックエンド1つに対して2つ持てるようになり、開発環境数が実質2倍に拡張 - 誰でもデプロイ可能になり、環境ごとのデプロイ担当者の区別がなくなった - テストチームが環境変数を一元管理できるようになり、管理コストを大幅削減 ## 使用技術 AWS ECS on Fargate / AWS S3 / CloudWatch Logs / FireLens + fluent-bit / GitHub Actions

## プロジェクト概要 エンタープライズ向けECプラットフォームにおいて、複数のバッチ処理が単一コンテナ上（複数イメージを持つ Dockerfile）で稼働する構成のため、コンテナ内でリソース（メモリなど）の競合が発生し、2件のパフォーマンス障害が生じていた。スペックアップによる対処を試みたが改善が見られず、根本原因の調査と構成変更によって解決した。 ## 担当したこと **問題1: OpenSearch インデックス更新バッチの遅延** - 商品情報の更新を OpenSearch に反映するバッチが1万件あたり約1時間かかっており、サービス利用企業の商品情報更新に大幅な遅延が発生 - スペックアップを試みたが効果なし → コンテナ内のリソース競合が根本原因と特定 - バッチを独立したコンテナとして切り出し、リソース競合を解消 - 改修スケジュールの策定・全環境への展開計画・テストチームおよびインフラチームへの協力依頼を主導 **問題2: 注文完了メールバッチの遅延** - アクセス集中時に注文完了メールの送信が15分以上かかるケースが発生 - 同様のコンテナ内リソース競合が原因と特定し、同じアプローチでコンテナを分離 ## 工夫した点 障害の初期対応としてスペックアップが実施されていたが、効果がなかった。「スペックアップで改善しない = リソースの割り当て量の問題ではなく、競合の構造的な問題」という仮説を立て、コンテナ構成レベルで検証した。この視点の転換が根本解決につながった。また、2件の障害が同一の根本原因から派生していると気づき、コンテナ分離という一つのアプローチで両問題を同時に解決できる設計を選択した。 ## 成果 - OpenSearch 更新バッチの処理時間を **約1時間 → 約5分（約92%削減）** に短縮 - 注文完了メールのアクセス集中時遅延を解消 - 単一の構成変更で複数の障害を同時解決し、開発コストを最小化 ## 使用技術 AWS ECS on Fargate / AWS Batch / Docker / Go（Echo）/ OpenSearch

本件はフランチャイズ案件を紹介するBtoCサービスのリニューアルプロジェクトです。 ## プロジェクト概要 元々外注で作製されたプロダクトですが、サーバーのOSやPHPのバージョンが古い上にハードコーディングされていたので、メンテナンスがしづらく、パフォーマンスが著しく悪い状態でした。本プロジェクトでは下記二点を行いました。 1. Laravelで作製された一般画面と管理画面 - サーバー移管 - PHPバージョンアップ - 機能修正 2. Zend Frameworkで作製されたフランチャイズ業者管理画面 - サーバー移管 - PHPバージョンアップ - CodeIgniterへのリプレイス ## 開発体制 本プロジェクトはGitLabを用いたチーム開発で、ウォーターフォールで進行しました。 ## チーム構成・規模 - インフラ：1 - フロントエンド兼バックエンド：1 - 企画：１ 私の役割としては上記の「フロントエンド兼バックエンド」に該当し、業者管理画面のCodeIgniterへのリプレイス、一般画面の速度チューニング、その他要望のあった修正、リリースまでを行いました。特に、業者管理画面は仕様書やドキュメントがない上に、依頼側の部署でも挙動を正確に把握している人がいなかったため、ソースコード（Zend Framework）を読むことで実際の仕様を把握していきました。 ## 解決した課題 元々のプロダクトではいくつかの一般画面、特にフランチャイズ業者の開催する説明会に関連するページ、が動作が重く開くのに数十秒かかっていて、複数人のユーザーがアクセスするだけでアプリ全体がフリーズしてしまい管理画面が固まってしまうという挙動が散見されていました。そこで、一般画面における速度チューニングを行いました。その結果、PHP関数で計測した処理速度は一番遅い箇所で20秒から0.2秒にまで改善されました。 ### 工夫した点 速度改善による具体的な知見を持っている人が周囲にいなかったので、基本的に自分で調べながら下記のようなアプローチで速度チューニングを行いました。 1. PHP関数を利用して各ページ表示に関与するfunction内で速度計測を行い処理速度を調べ、時間がかかっている箇所を列挙していきました。 2. 「達人が教える webパフォーマンスチューニング」（技術評論社）という本をざっと読みデータベースチューニングを実施しました。特に遅い箇所のSQLを抽出して、EXPLAINで検証する作業を行いました。 3. PHPサイドでも無駄なSQLが発行されていないか、重い処理を行っていないかをチェックし、メモリを食っている箇所はリファクタリングを行いました。 上記を実施した結果、①説明会に関連するページは説明会のカラムにindexが貼られていない、②SELECT文が✳︎になっていた、③foreach分の中でSQLを発行している箇所が数箇所あった、ことがわかり改善したところ、一番遅い箇所で20秒から0.2秒にまで改善されました。 ## 習得した技術 上記の開発経験を経て、下記の技術を身につけました。 1. 速度チューニング ## リリースと成果 本件は2022年9月末にリリースされ、現時点まで正常に稼働しています。パフォーマンスが向上したことで検索順位が著しく上がりました。