ID:73505さん

# プロジェクト経験概要 チケット管理サービスの受託開発。0→1から約1年で1日最大140万アクセス規模まで成長。 - 主な担当領域：サーバーサイド（リーダー）／インフラ・DevOps（兼任） # チーム情報 - チーム構成：自社側4名（フロントエンド2名 / サーバーサイド2名）。受託案件のため、先方要望によりディレクターは非配置。 - 自身の役割：サーバーサイドのリーダー。難易度の高い設計・実装を担当し、分解した簡易タスクをジュニアへ委譲。インフラ／DevOps（CI/CD・環境構築）は一人で担当。 - 立ち上げの前提：先方エンジニアが初期基盤（作業者用IAMロール・ネットワーク）を構築した後、以降の構築・運用を全面的に引き継ぎ。 > 以下の各項目は、先方が構築した初期基盤・GitOpsの仕組み（開発・実装内容Cの土台）を除き、いずれも自身が単独で設計・実装したもの。 --- ## 課題解決型（自身で課題を発見し、打ち手を設計・実装したもの） # 開発・実装内容A：RDSの非効率クエリ改善によるコスト削減 【概要】 RDS Performance Insights で非効率クエリを特定・改善し、Aurora Serverless v2 のACU低下によりRDSコストを約78%削減。 【課題・問題点】 負荷上位クエリに適切なインデックスが無く対象テーブルをフルスキャンしていたため、レコード数に比例してCPU使用量が高騰していた。これが Aurora Serverless v2 のACU上昇（=コスト増）として顕在化していた。 【打ち手・使用した技術】 Performance Insights で負荷上位のクエリを特定し、該当クエリにインデックスを追加した。 【成果】 負荷低下に伴い Aurora Serverless v2 のACUが下がり、RDSコストを約78%削減した。 # 開発・実装内容B：決済処理の本番障害対応（トランザクションタイムアウトの解消） 【概要】 決済レコード作成時に頻発していたトランザクションのタイムアウトを、原因調査のうえ解消。 【課題・問題点】 決済レコード作成時にトランザクションのタイムアウトエラーが頻発していた。 【打ち手・使用した技術】 当初はDB側の問題と思われたが、RDS Performance Insight で調べたところDB側のスペックには余裕があった。 さらに調査を続けるとECS側のCPU使用量が逼迫しており、以下のような原因ではないかと仮説を立てた。 - 巨大なループ処理が Node.jsのシングルスレッドを占有し、トランザクション内の処理をブロックしている - 特定テーブルのレコードを全件取得してアプリ側で絞り込んでいる箇所があり、そこが原因となっている 該当部分をDBで絞り込むよう修正したところ、タイムアウトエラーが出なくなった。 PoC段階の小データ量では問題化しなかった Devin の富豪的実装が、サービスのスケールに伴って顕在化した形だった。 【成果】 トランザクションタイムアウトを解消し、決済処理を安定化した。 --- ## タスク実行型（先方の基盤・要件を起点に、構築・遂行を担当したもの） # 開発・実装内容C：GitOps基盤上での本番／STGインフラ構築（Terraform） 【概要】 先方が確立した高度なGitOpsの仕組みを土台に、本番インフラの約9割とステージング環境一式をTerraformで構築。 【前提・役割】 受託スキーム上、先方は初期基盤（IAM・ネットワーク）と設計のみを担い、アプリの商用運用に必要な本番インフラ（配信・ルーティング・コンピュート・DB・監視等）の大部分は、受託側である自身が構築する役割分担だった。 【扱った技術・構成】 GHAのApply実行トリガーをGitHubのUI操作に紐づけた構成とし、GHA内でplan出力に静的解析をかけ、破壊的変更を含むPRへ自動でラベルを付与する仕組みを踏襲して構築した。構築した主な本番構成は以下のとおり。 - 配信：Route53・ACM・CloudFront＋S3・Amplify - ルーティング：ALB - コンピュート：ECS Fargate - DB：Aurora - 監視：CloudWatch - デプロイ：CodePipeline - ログ転送：Kinesis 【得られた知見】 本番の約9割とSTG一式を構築し、以下のようなGitOps／IaC環境での実装知見を獲得した。 - 基本的なTerraformによるインフラ管理の知見 - Terraformのモジュール化によるコードの抽象化に関する知見 - OIDCによりGithub ActionsからAWSのリソース操作を行うアプローチ - CIで特定のアクションの出力を静的に解析する手法 # 開発・実装内容D：RoR から Hono + TypeScript へのフルリプレイス 【概要】 他エンジニアが RoR で開発していた当該プロジェクトを、先方要求に基づき TypeScript へフルリプレイス。移行手段の選定と遂行を担当。 【前提・要求】 先方に Ruby が読めるエンジニアがおらず、保守性の観点から TypeScript へのフルリプレイスの要求があった。 【打ち手・使用した技術】 AIコーディングエージェント Devin を用い、リゾルバ単位で一括移行する方針を採用。移行先には Hono・TypeScript を用いた。 【成果】 先方が読める TypeScript ベースへ刷新し、無事納品できた。 # 開発・実装内容E：納品要件に基づき構築したその他インフラ 【概要】 先方の納品要件に沿って構築したもの。 【打ち手・使用した技術】 - CodePipeline ＋ ECS（CodeDeploy）による Blue/Green の自動デプロイ - 監査ログの長期保存要件に対し、CloudWatch Logs → Kinesis Data Firehose → S3 のログ転送基盤

# プロジェクト経験概要 イベント向けチケット（参加申込・受付）管理アプリの新規開発（0→1フェーズ）。マルチテナント構成で、テナントごとにイベント・チケットを管理 - 主な担当領域：サーバーサイド（リーダー）／インフラ・DevOps（兼任） # チーム情報 - チーム構成：合計5名（ディレクター1名 / フロントエンド2名 / サーバーサイド2名）。インフラは自身が兼任 - 自身の役割：サーバーサイドのリーダー。難易度の高い設計・実装を担当し、分解した簡易タスクをジュニアへ委譲。インフラ／DevOps（CI/CD・環境構築）は一人で担当 - 開発体制：スクラム開発。コードはGitHub管理・マージにPRレビュー必須、タスクはLinearで管理 以下の「開発・実装内容A〜E」は、いずれも**自身が単独で設計・実装**したもの --- # 開発・実装内容A：PR単位の独立プレビュー環境の自動構築基盤 【課題・問題点】 ステージング環境が1つのみで、複数PRのQAが並行して進められなかったため、チーム内でPRごとに立ち上がる検証環境が欲しいという声が上がった。 【打ち手・使用した技術】 当初はKubernetes（EKS）を実行基盤として検討するも、以下の理由で棄却した。 - 常設Nodeの金銭的コスト - Nodeスペックが同時起動できる検証環境数の上限になりうる点 - 自分以外にK8sを運用できるメンバーの不在 そこでFargateを実行基盤として、以下のようなアプローチをとった。 - ecspressoでECSタスク内に必要コンテナをサイドカー構成で定義 - PRに特定のラベルを付与すると起動するようGitHub Actionsを構成 - コスト削減のためFargate Spotを採用し、NAT Gatewayの代わりにNat Instanceを使用 【成果】 本番環境に比べネットワーク構成等がやや異なるが、 ほとんどのPRはアプリケーションレイヤーの動作修正で完結しているためこれで十分。 並行・独立検証が可能になり、QAの順番待ちを解消できた。 またラベル起動方式により、必要なときだけ低コストで環境を用意できるようになった。 # 開発・実装内容B：GitHub Actions のサプライチェーンセキュリティ強化 【課題・問題点】 近年Github Actionsはnpmに次ぐサプライチェーン攻撃の温床となりつつあり、既存の実装のままだと以下のようなリスクがあった。 - タグ参照のActionは差し替えリスクがあり、悪意あるコード混入の懸念 - 過剰権限によるアカウント・トークン乗っ取り時の影響範囲の拡大 【打ち手・使用した技術】 以下のような手法を用いた。 - PinactでサードパーティActionの参照をタグからコミットSHAに固定し、RenovateでSHAを安全に追従・更新 - 各ワークフロー／ジョブの `permissions` を最小化 - GitHub Actions–AWS間はOIDC連携とし、静的なIAMアクセスキーを排除（OICD用ロールも権限最小化を意識） 【成果】 - Action差し替えによるコード実行リスクと、過剰権限によるリスクを低減できた。 # 開発・実装内容C：Row Level Security によるマルチテナンシー 【課題・問題点】 テナント管理者側ではテナント間のデータを許容できないが、ユーザー側はテナントを跨いだ操作を許容しないと煩雑になってしまう、という問題があった。 【打ち手・使用した技術】 ユーザー側のテナント間データ時点を許容する時点で、DBやスキーマ自体を分離するアプローチは取れない。 しかしアプリレイヤーだけでテナンシーを実現すると、実装ミスによるテナント越境が懸念された。 そこでRLSを用いるアプローチを取った。 - テナント管理者用のリゾルバでは接続単位で `SET LOCAL` により許可組織IDを渡す - ポリシーの `USING` 句で `current_setting()` を参照して可視行を制御 - CIで各テーブルへのポリシー付与が行われているかをチェックするように 【成果】 アプリレイヤーの実装でテナント越境を懸念しなくても良くなったため、認知負荷の低いセキュアな開発フローが実現できた。 # 開発・実装内容D：fincode を用いたトークン型決済システムの整合性設計 【概要】 fincode を用いたトークン型決済を、分散システムの不整合が起きないよう設計・構築 【課題・問題点】 DBと外部決済APIをまたぐため、不整合を防ぐためにはどちらかの失敗が起きた時に補償処理を行う必要がある。 しかしチケット確保・決済を一つにまとめたところ例外発生時の補償処理があまりにも複雑化し、保守困難なコードになってしまった。 【打ち手・使用した技術】 処理を2つのGraphQLミューテーションに分割し、リトライ可能な構造に 1. チケット確保 ＋ fincodeへの決済登録 2. 登録済み決済の実行（確定はWebhookで受領） 各ステップにSagaパターン的に小さな補償処理を定義し、途中失敗時もDBと決済状態の整合を回復 【成果】 分散システムの不整合を防ぎつつ、保守性の高いシンプルなコードを設計を行うことができた。