ID:73505さん

# プロジェクト経験概要 エンタメ系サービス（イベント連動でアクセスが変動）の運用・改善フェーズ。日間50万PV規模。 - 主な担当領域：インフラ・DevOps／バックエンド # チーム情報 - 既存運用中のサービスにジョインし、インフラ／バックエンドを担当。 - 以下の「開発・実装内容A〜E」は、いずれも自身が単独で設計・実装したもの。 --- # 開発・実装内容A：レガシー本番EC2環境のリプレース（Immutable AMI ＋ ASG） 【概要】 Amazon Linux 2 のEOLを契機に、属人化したレガシー本番EC2環境を Packer による Immutable AMI ＋ ASG 構成へゼロダウンタイムでリプレース（現在進行中）。 【課題・問題点】 本番EC2が「秘伝のタレ」化。環境固有値をインスタンス内に直書きし、デプロイもインスタンス内での git pull 運用。構成がコード化されておらず、自分しか触れない属人的な状態だった。 【打ち手・使用した技術】 当初は以下の理由からFargate を検討。 - Fargate + ecspresso ＋ GHA デプロイのPJが増えており、揃えることで他エンジニアの認知的負荷を下げられる - コンテナ化によりオートスケーリングが高速化すればスケジュールスケーリングを不要にでき、稼働台数が下がる可能性がある ただし以下の理由により棄却 - Fargate 自体のコスト増 - 固定IPしか受け付けない外部APIとの通信に NAT Gateway が必要となりさらにコスト増 - RoR ではどのみちイメージが重いため、 Fargate にしたところでスパイクにオートスケールが追いつかない。 そこでPacker で環境固有値・依存関係を取り込んだ Immutable AMI を作成し、ASG 構成へ移行。 - インスタンス内 git pull 運用を排除 - デプロイは、Packer を GHA で実行すると OIDC 用ロールへ過大な権限を付与する必要があるため、CodePipeline を採用 - 切替は新しいターゲットグループへ向ける方式とし、ゼロダウンタイムを担保 【成果】 - 属人化した本番環境をコード化し、AL2 EOL に向けたOS移行の道筋を確保。再現性のある構成へ移行（現在進行中） # 開発・実装内容B：手構築の本番環境のフルIaC化（Terraform） 【概要】 手構築でコード管理外だった本番環境を Terraform import でフルIaC化。 【課題・問題点】 - 本番環境が手構築でコード管理外にあり、変更が属人的でレビューも効かず、再現性が無かった 【打ち手・使用した技術】 本番環境・STG環境が同一アカウント上に相乗りしていたため、terraformer 等の自動インポートツールを用いると環境が混在したコードになる恐れがあった。 そこでスコープを明示的に絞った import を採用。 対象リソースとその周辺リソースに限定して Amazon Q developers に import ブロックを生成させ、terraform plan -generate-config-out で設定ファイルを起こし、再利用・レビュー可能な粒度へモジュール化して整理。 import に習熟しており、小規模環境なら2h以内で完了できる。隙間時間で実施した。 【成果】 - 本番のコード化で再現性・レビュー性を確保し、属人性を低減 # 開発・実装内容C：RDS Blue/Green デプロイの半自動化（Step Functions） 【概要】 RDSバージョンアップ時の手動オペレーションを、Step Functions による Blue/Green デプロイの半自動化フローとして設計・実行。 【課題・問題点】 複数PJで RDS バージョンアップに伴う手動のインスタンス再起動が発生。以下のような工程を行う必要がある。 1. http status 503 を返すように ALB を調整 2. DBへのリクエストが途絶えたことを確認 3. Blue/Green の switchover 4. DBが ready になったことを確認 5. ALB を通常稼働へ復帰 ステージングで手作業のリハーサルを行ったところ、15分ほどかかりミスも発生した。 本番環境でダウンタイムを入れるため、可能な限り早く復帰することが望ましかった。 加えて他PJでも RDS バージョンアップ時に同様のオペレーションが必要になるため、自動化するべきだと判断した。 【打ち手・使用した技術】 Step Functions で Blue/Green デプロイの手順を半自動化するステートマシンを作成した。 - AWS 上の各種リソースをGUIで直感的に操作でき、Lambdaより少ない工数で実装・検証可能。 - 一度 IaC 化すれば他PJでも使用可能。 - フローは 3 までを前半、4 以降を後半として2つの Step Functions に分割。トラブル発生時に手動で介入できる余地を残した。 【成果】 - 手動だと毎回手の止まっていた切替オペレーションを、1サービスあたり10分以内で完了できるようにした。 - Terraform 化により複数PJへ横展開可能な標準手順として整備。属人的な手動再起動を排除。 # 開発・実装内容D：イベント時刻に基づく予測型スケジュールスケーリング 【概要】 DBに記録されたイベント時刻からピークを事前予測し、スケジュールスケーリングでピーク前にキャパシティを確保する仕組みを設計・構築。 【課題・問題点】 RoR アプリを ASG に載せてもスケールアウトが遅い。起動時に git pull ＋依存関係インストールを行うため1インスタンス追加に5分以上かかり、リアクティブなオートスケールではアクセス急増に間に合わなかった 【打ち手・使用した技術】 DBに記録されたイベント時刻からピークタイムを事前予測し、アプリ側の設定を起点にスケジュールスケーリングを実行。リアクティブではなく予測型でピーク前に増設する構成とした 【成果】 起動遅延の制約下でもピーク時の処理能力を事前確保し、アクセス急増時の取りこぼし・遅延を抑えた。

# プロジェクト経験概要 イベント向けチケット（参加申込・受付）管理アプリの新規開発（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と決済状態の整合を回復 【成果】 分散システムの不整合を防ぎつつ、保守性の高いシンプルなコードを設計を行うことができた。