Kazuki

### プロジェクト経験概要 新規リリースするスマートフォンアプリ・Webサービス向けの監視基盤を、設計からゼロで立ち上げた案件。リリースまで残り1ヶ月半の時点で監視設計が白紙、かつ監視・オブザーバビリティ（以下 o11y）の有識者が不在という状況だった。緊急のサポート要員として私一人で、要件ヒアリング・アラート選定・設計・Terraform による実装・引き継ぎ資料の作成までを約1ヶ月で完遂した。 ### チーム情報 - 監視基盤の担当: **私1名**（設計・実装・ドキュメントの全工程） - 連携先: アプリ開発チームのメンバー、チームリーダー（〈要記入: 関係者の人数、自分の役職/等級〉） - 使用技術: AWS（CloudWatch Logs / Logs Insights / サブスクリプションフィルタ / メトリクスフィルタ、Amazon Data Firehose、Amazon Athena、S3）、Terraform、GitHub Projects ### 開発・実装内容A: アラート設計方針の策定と関係者合意 **【概要】** 監視対象・通知先・閾値を決める前段として、「どういうアラートを鳴らすか」の判断基準そのものを定義し、関係者の合意を取った。 **【どのような機能の開発・実装か】** アプリチームへのヒアリングを **私が主導** し、通知数の想定と将来的な o11y の方向性を引き出したうえで、「**通知を受け取る＝アクションを起こす**」を監視基盤全体のゴールとして設定。このゴールに合致しないアラートは実装しない、という設計原則を文書化した。 **【課題・問題点】** - リリースまで1ヶ月半の時点で監視設計が何もない状態だった - 社内に o11y の有識者がおらず、何を基準にアラートを選ぶかの判断軸が存在しなかった - 判断軸がないまま実装すると、鳴り続けて誰も見なくなる「アラートのオオカミ少年化」に陥る見込みが高かった **【打ち手・使用した技術】** - **私から** o11y におけるアンチパターンと、現チームの体制で現実的に取り入れられる考え方を整理して共有し、議論の土台を作った - そのうえで上記のゴールを提案し、アプリメンバーとチームリーダーの合意を取得 - アラートを「アプリが出力するログベースのエラー」と「AWS サービスが出力するメトリクスベースのエラー」の2軸に分類し、GitHub Projects の issue 単位で設計・進捗管理 **【成果】** - 白紙の状態からリリースに間に合う形で監視設計を確定（〈要記入: 最終的に実装したアラート数／そのうち通知対象に絞った数〉） - 〈要記入: 運用開始後の通知件数、誤検知率、対応につながった割合など。ゴールが機能した裏付けになる数字〉 ### 開発・実装内容B: ログ分析基盤の構築 **【概要】** アプリのログを低コストで検索・分析できる基盤を構築した。 **【どのような機能の開発・実装か】** TraceID や durationMS を含むトレーサビリティ前提のログ体系は、すでにアプリ側の要件として実装済みだった。**私はこれを前提として活用する側の基盤** を設計し、CloudWatch Logs からサブスクリプションフィルタ経由で Amazon Data Firehose に流し、S3 に蓄積して Amazon Athena でクエリする構成を Terraform で構築した。 **【課題・問題点】** - ログを CloudWatch Logs に保持し続ける構成ではコストが想定を超える見込みだった - 一方で、障害調査時には TraceID を軸にした横断検索が必要で、検索性は落とせなかった **【打ち手・使用した技術】** - 直近の調査は CloudWatch Logs Insights、長期・大量のログは S3 + Athena に分離し、保持コストと検索性を両立 - CloudWatch Logs、Logs Insights、サブスクリプションフィルタ、メトリクスフィルタ、Amazon Data Firehose、Amazon Athena、S3 を 選定し、全て Terraform で実装 ### 開発・実装内容C: Terraform モジュール化と引き継ぎ体制の整備 **【概要】** 自分が抜けたあとも運用・拡張が続けられるよう、実装のモジュール化とドキュメント整備を行った。 **【どのような機能の開発・実装か】** メトリクスとアラームの Terraform モジュールを **私が作成** し、README に使い方とサンプルコードを記載。あわせて、各アラートの設定意図と閾値の根拠をまとめた資料を作成した。 **【課題・問題点】** - アラート・メトリクスの実装数が膨大になり、同じ記述の繰り返しが発生する見込みだった - 短期参画のため引き継ぎが前提で、引き継ぎ後にアラートを「設定する／しない」を後任が判断できる必要があった - チーム内に CloudWatch Logs と Amazon Athena に不慣れなメンバーが多く、基盤を渡しても使われない恐れがあった **【工夫】** - Terraform モジュール化により、大量のアラートルール追加が必要になった際も宣言的に追加できる構造にした - モジュールの README にサンプルを添え、新規参画者が参照するだけで追加できる状態に - CloudWatch Logs / Athena の使い方を別途 README として用意し、チームへ共有 - アラートごとの設定意図・閾値・判断根拠を資料化し、引き継ぎ後の判断材料として残した

### プロジェクト経験概要 所属部署として初めてのマイクロサービス導入プロジェクトに、**業務委託の SRE 兼インフラエンジニアとして参画**。社内の複数サービスから利用される共通マイクロサービスという位置付けで、**アーキテクチャ設計・技術選定の検証・AWS リソース構築・CI/CD 整備・o11y のツール選定を主導**した。ロールは SRE だったが、インフラ領域の有識者が不在だったため、初期フェーズでは AWS 設計・構築をリードするインフラエンジニアとしても動いた。**今回のスコープは dev 環境の設計・構築**で、本番リリースは2027年を予定している。離任時には、**SRE 側のメインタスクを完了させ、設計・運用資料を整備したうえで、アプリ側の実装待ちという状態にして引き継いだ**。 ### チーム情報 - SRE: **2名**（私と、社会人2年目の後輩1名）。**打ち合わせの主催とファシリテート、技術的な相談への回答、タスク分解・方向性の提示、後輩の指導まで、SRE 側をほぼ私がリード** - 連携先: 複数のアプリ開発チーム（〈要記入: 関係者の総人数、アプリチーム数〉） - 私の担当: アーキテクチャ設計、技術検証、レビュー、Terraform によるリソース構築、GitHub Actions による CI/CD、o11y のツール選定、インフラ観点のリード - チーム運営面: **SRE タスクの起票と分解**、定例の主催・ファシリテート、**他チームへの情報共有**、後輩のタスク進捗の把握と技術相談への対応 - 契約形態: 業務委託 - 使用技術: AWS（**ALB、ECS、Aurora、DynamoDB（Streams）、Lambda、SNS、SQS/DLQ** をメイン構成。Kinesis Data Streams は採否を検証し不採用）、Terraform、GitHub Actions - 設計パターン: **CQRS**（書き込み系と読み込み系を分離） ### 開発・実装内容A: CQRS 構成によるマイクロサービス基盤のアーキテクチャ設計と技術選定 **【概要】** 全社の各サービスが共通して参照する情報（企業情報、顧客名など）を1箇所に集約することを目的としたマイクロサービス。その AWS アーキテクチャを CQRS 構成で設計し、dev 環境への実装と、本番リリースまでの段階的な構築計画に落とし込んだ。 **【どのような機能の開発・実装か】** ALB、ECS、Aurora、DynamoDB、Lambda、SNS、SQS を中心としたアーキテクチャを設計。書き込み系と読み込み系でモデルと経路を分離する **CQRS 構成** を採用した。 - **Command 系（書き込み）**: ALB → 書き込み用 ECS → DynamoDB。リクエストをいったん DynamoDB に保存して受け切る - **Processor 系（非同期処理）**: DynamoDB Streams → Lambda → SNS → SQS（DLQ）→ 処理用 ECS → **Aurora**。保存をトリガーに、Aurora への反映を非同期で実行 - **Query 系（読み込み）**: ALB → 読み込み用 ECS → **Aurora** へ直接クエリ。書き込み経路の DynamoDB は経由しない 最初に作るマイクロサービスの特性と想定リクエスト数をもとに、書き込み経路に Kinesis Data Streams を挟むかどうかを **検証したうえで判断**。あわせて、データ損失を防ぐ経路として SNS と SQS（DLQ）の採用も設計に織り込んだ。 **【課題・問題点】** - 部署としてマイクロサービスの導入実績がなく、参照できる社内事例も有識者もいなかった - 共通マスタという性質上 **参照が主体で書き込みは少量** という想定だったが、全社の各サービスから参照されるため読み込み側の負荷は読みにくかった - 事業部が将来達成したい目標と、最初のマイクロサービスに必要な要件との間に認識の開きがあった - 一度に完成形を作ると、検証されていない構成がそのまま本番リリースに向かうリスクと、運用負荷が読めないまま引き渡すリスクがあった **【打ち手・使用した技術】** - 事業部の将来目標を関係者とすり合わせ、**完成形から逆算して段階的な構築ステップを定義**。どこまでを第一弾に含めるかを明示した - 書き込みが想定より増えた場合に備え、**DynamoDB + Kinesis Data Streams を挟む構成も検討・検証**。想定リクエスト数から **書き込み処理が詰まる可能性は低い** と判断し、**採用しない方針を決定**した。運用対象を増やさないことを優先した判断 - **書き込みを Aurora へ同期で流さず、DynamoDB でいったん受け切る構成に分離**。Streams を起点に非同期で Aurora へ反映することで、書き込みが増えても Aurora 側のコネクションを圧迫せず、後続処理の遅延がレスポンスに波及しないようにした - Streams から SNS へは直接つなげないため、**間に Lambda を挟んで連携** - **読み込み系は書き込み経路を通さず、ALB から Query 用 ECS を経て Aurora へ直接クエリ**。全社のサービスから参照される **読み込みが主体**で、書き込みは大量に発生しない想定だったため、**負荷の大きい読み込み側だけを独立してスケールできる構造**にすることを狙って CQRS を採用した - 可用性要件に対しては SNS + SQS（DLQ）でデータ損失経路を潰す設計を採用 - 将来の o11y 運用を見据えて監視・計測ツールを選定（〈要記入: 選定したツール名と、比較した候補・選定理由〉） - 設計判断は **ADR として文書化** し、属人化を防いだ **【成果】** - **dev 環境にアーキテクチャを構築し、インフラ層でのデータ連携まで確認済み**（ALB → 書き込み用 ECS → DynamoDB → Streams → Lambda → SNS → SQS → 処理用 ECS → Aurora の経路が疎通する状態）。アプリ側の実装が未完了のため、サービスとしての動作検証はそこから先の工程（本番リリースは2027年予定） - 書き込み経路に Kinesis Data Streams を**採用しない判断を検証のうえで下し**、不要な構成要素と運用対象を増やさずに済ませた ### 開発・実装内容B: アプリチームとの要件調整と進行管理 **【概要】** アプリ開発チームが AWS リソースを使った開発に着手できる状態を作るため、定例を主催して要件と設計の乖離を潰した。 **【どのような機能の開発・実装か】** アプリメンバーと関係者を含めた定例を主催・ファシリテートし、アプリ側の想定要件と設計の差分確認、タスク分解、ブロッカーになりそうなタスクの期日・優先度調整を行った。打ち合わせの場で挙がる技術的な相談への回答も、**SRE 側の窓口としてほぼ一手に引き受けた**。 **【課題・問題点】** - SRE が2名のみ、うち1名は社会人2年目という体制で、指示待ちでは進まない状況だった - アプリチームとインフラ設計の間で要件認識がずれると、手戻りが開発スケジュールを直撃する構造だった - 特定タスクがブロッカー化すると、アプリ側の着手自体が止まる依存関係があった - 技術的な相談が定例外にも発生し、後輩が単独で受けると回答精度が安定しないリスクがあった **【打ち手・使用した技術】** - 定例の主催とファシリテートを担い、要件と設計の差分をその場で洗い出す運用にした - 後輩に対しては **タスクを分解して方向性を提示する形で指導** し、独力で進められる単位まで落とした - 定例外の追加ヒアリングは **後輩を窓口にして質問を集約**し、**回答予定の内容をレビューしてから返す運用**にした。回答の品質を担保しつつ、後輩が実際に受け答えする経験を積める形にした - ブロッカー候補を先に特定し、期日と優先度を調整してアプリ側の着手を止めないようにした - 構築はタスク状況に応じて **マネジメントコンソールと Terraform を使い分け**、スケジュールを優先すべき局面では手動構築を選んだうえで後から IaC に寄せた **【成果】** - 離任時点で **SRE 側のメインタスクは完了**。インフラは構築・疎通確認済みで、残るはアプリ側の実装のみという状態まで進めて引き継いだ ### 開発・実装内容C: ドキュメント導線の整備（オンボーディング改善） **【概要】** 新規参画メンバーが情報を取得するまでの時間を短縮するため、ドキュメント類を参照導線ごと整備した。 **【どのような機能の開発・実装か】** 議事録・ADR・アーキテクチャ図・AI レビューの手順・コーディングルールを、**Claude Code のプラグインとして配布物にまとめ**、開発環境から直接参照できるようにした。 **【課題・問題点】** - SRE 以外のメンバー（アプリ、PO）が多く、資料の置き場所が分散していて探すのに時間がかかっていた - 新規参画のたびに同じ質問が発生し、キャッチアップに時間がかかっていた - 同じ質問を複数回聞かれることで、既存メンバーの時間も奪っていた - コーディングルール(Terraform,Ecspresso)を別々のリポジトリに配置しており、似たような内容が重複する可能性があった。初期フェーズのため現時点では Terraform 本体とモジュール用、アプリ用の3リポジトリだが、**リポジトリが増えるほど重複と更新漏れが拡大する構造**だった **【打ち手・使用した技術】** - 参照頻度の高いドキュメントを1つの配布物に内包し、**探す手間自体をなくす方向で解決**（検索性を上げるのではなく、置き場所を1箇所に固定） - 内包する対象と構成を設計し、**Claude Code のプラグインとして実装**。あらかじめ決めた場所へすぐにアクセスできるようにした **【成果】** - 複数のリポジトリに同じコーディングルールを配置する必要がなくなり、**1箇所の修正で全リポジトリに反映できる**ようになった（現在は2リポジトリ。今後の増加を前提とした構成） - メンバーが画面を開いて資料を探す手間がなくなり、**Claude が検索している間は他の作業に集中できる**ようになった - **情報の格納先を知らないメンバーでも、ある程度の情報を自力で取得できる**ようになった

### プロジェクト経験概要 EC2 上で稼働していた自社サービス（WordPress / PHP）を ECS へ移行した案件。**移行方式の設計から Terraform による実装、本番切り替えまでを担当**した。事業部の新規サービスが全て ECS で稼働しているなか、このサービスだけが EC2 に残っていたため、基盤と Terraform の管理方針を揃えることが目的だった。 ### チーム情報 - SRE主体でdockerfile,CICD,ECSタスク定義を作成。 - アプリメンバは3人、SREは2名で対応 - 使用技術: AWS（ECS、EC2、ALB）、Terraform、WordPress / PHP ### 開発・実装内容A: 利用者への影響を出さない移行方式の設計 **【概要】** 稼働中のサービスを止めず、利用者が基盤の変更に気づかない形で ECS へ移行する手順を設計した。 **【どのような機能の開発・実装か】** 移行方式を設計し、ドメイン名を変更せずそのまま流用する構成とした。切り替え手順とロールバック手順を定義し、リリース失敗時に即座に戻せるよう、移行元 EC2 の削除をリリース完了から数日後に設定した。 **【課題・問題点】** - **事業部の新規サービスは全て ECS で稼働しているなか、このサービスだけが EC2 に残っていた。** 基盤が揃わず、Terraform での管理方針も統一できない状態だった - 稼働中の自社サービスであり、切り替え失敗がそのまま利用者への影響になる - 失敗した場合に、調査や再デプロイを待たず**短時間で元に戻せる**必要があった **【打ち手・使用した技術】** - ドメイン名を据え置くことで、利用者側の設定変更やブックマーク切れを発生させない構成に - **ALB のリスナールールを EC2 向け・ECS 向けの2本あらかじめ用意し、優先順位の入れ替えだけで切り替わる構成を実装。** DNS の伝播を待つ必要がなく、**エラーが出たら優先順位を戻すだけで即座にロールバックできる** - Terraform をマージすると本番環境へデプロイされる仕組みのため、**アプリメンバーへ事前周知したタイミングでマージし、切り替え準備を当日までに全て完了**させた。当日に実施するのは優先順位の入れ替えのみ - 移行元 EC2 を即時削除せず数日残すことで、ALB のルールを戻す以外のロールバック手段も確保 **【成果】** - **切り替えもロールバックも ALB のルール優先順位の変更だけで完結する状態**を作り、当日の作業と失敗時の復旧をどちらも最小手数に抑えた - 事業部の新規サービスと基盤・Terraform の管理方針を統一 ### 開発・実装内容B: 横展開を前提とした Terraform モジュール整備 **【概要】** 同種の WordPress サービスが他にも存在したため、次回以降の ECS 化を再利用で済ませられるようモジュール化した。 **【どのような機能の開発・実装か】** 移行対象の構成を Terraform モジュールとして切り出し、類似構成のサービスでも流用できる形に整備した。 **【課題・問題点】** - 社内に同様の構成の WordPress サービスが複数あり、同じ移行作業の繰り返しが見込まれていた - 個別に書き下ろすと、移行のたびに設計と実装のコストが同じだけ発生する **【打ち手・使用した技術】** - 今回の移行をそのまま終わらせず、**再利用可能な単位に分解して Terraform モジュール化** **【成果】** - モジュールを利用することで残りのサービス(EC2稼働)１つにき、１週間程度で移行が完了するようになった

### プロジェクト経験概要 大手外資企業で稼働する 1,000台以上の Windows EC2 に対し、スケジュールされたパッチを自動適用する仕組みを **設計から実装まで担当**した。本番環境かつ障害時の影響が極めて大きい環境で、部署を跨いだスケジュール合意の取得から、Lambda を用いた自動化機構の実装、並行しての OS アップデートまでを行った。 ### チーム情報 - クラウドベンダーとして自分を含め7名、設計、打ち合わせ時のファシリテート、スケジュール作成、Lambdaやそれ以外のAWSリソース作成・検証を担当 - 使用技術: AWS（Systems Manager Maintenance Windows / Run Command / Automation、Lambda、S3、SNS）、Windows Server ### 開発・実装内容A: 部署横断のパッチスケジュール合意と入力形式の設計 **【概要】** 手動管理されていた年次パッチ適用を事前にスケジュールとして、自動適用するためのインプット情報として形成した。 **【どのような機能の開発・実装か】** 各部署と調整してパッチ適用スケジュールの合意を取り、それを CSV 形式に定義して S3 へ保存する運用に落とし込んだ。S3へCSV の保存アクションをトリガーに、以降の処理が自動で走る設計とした。 **【課題・問題点】** - 対象が 1,000台以上あり、EC2 内で稼働する機能ごとに担当部署と適用タイミングが異なっていた - Windows Serverのバージョンもバラバラである程度揃える必要があった - 毎年必ず実施が必要なのに全て手動管理で、運用負荷が非常に高い状態だった - 自動化する以前に、部署ごとにバラバラな適用タイミングを合意させる必要があった **【打ち手・使用した技術】** - **部署間の調整を担当**し、適用タイミングの合意を取得 - 合意内容を CSV という**人が編集でき、かつ機械が読める形式**に落とし、運用の入り口を1つに統一 - S3 への保存イベントを起点にすることで、運用担当者が「CSV を置くだけ」で完結する導線にした **【成果】** - 年間スケジュールの作成・合意から完了通知までが、CSV を S3 に保存するだけで自動完了する状態を実現 ### 開発・実装内容B: パッチ自動適用機構の実装 **【概要】** CSV を起点に Maintenance Window を自動スケジュールし、結果を通知するまでの処理を実装した。 **【どのような機能の開発・実装か】** 4つ以上の Lambda を組み合わせた処理を実装。CSV の保存を検知して Systems Manager の Maintenance Window を自動スケジュールし、適用の成功・失敗をあらかじめ定義した担当者へ通知する。Lambdaを利用し複数リージョンへの同時適用にも対応させた。 **【課題・問題点】** - 本番環境であり、パッチ適用の失敗がそのまま大規模障害につながる - 適用結果を人が追いかける運用では、1,000台規模では確認が追いつかない - 対象が複数リージョンに分散していた - 担当者が各サービスごとにバラバラで都度把握するのが非常に困難だった **【打ち手・使用した技術】** - スケジュールを **リハーサル用と本番適用用の2種類に分割** し、本番前に問題を検知できるようジョブ設計 - 成功・失敗を担当者へ自動通知し、人が全台を確認する必要をなくした - Lambda を4つ以上に分割して処理を構成し、複数リージョンへの適用に対応 - AWS Systems Manager（Maintenance Windows、Run Command、Automation）、Lambda、S3、SNS **【成果】** - 稼働確認として10台ずつ適用を試し、プロキシ経由でエラーになる事象を複数検知 - 本番適用時の障害発生件数。ネットワーク設定見直しを別PJで対応し大規模な障害はなし ### 開発・実装内容C: 社内プロキシ環境での実行失敗の回避と OS アップデート **【概要】** 社内プロキシの制約で標準機能が動かない問題を回避し、並行して Windows の OS アップデートを実施した。 **【どのような機能の開発・実装か】** Automation ドキュメントを自作し、必要なパッケージをあらかじめ取得・保存しておく方式に切り替えた。あわせて、AWS のサポート期限が近い旧バージョンの Windows に対する OS アップデートも並行して実施した。 **【課題・問題点】** - 社内プロキシの影響でインターネット接続が通らず、Maintenance Window 内で動く Run Command や Automation が失敗するケースが頻発していた - Windows Server内でAutomation実行時に利用するサービスアカウント(LOCALSYSTEM)のProxy(InternetExplorerのプロキシ設定)が無効化されていなかった - Windows のバージョンが古く、AWS のサポート切れが近いサーバーが複数存在していた **【打ち手・使用した技術】** - AWS 提供の Automation をそのまま使うのをやめ、**必要なパッケージを事前取得・保存する自前の Automation を実装** して、実行時にインターネット接続を必要としない構成にした - パッチ適用機構の実装と OS アップデートを **並行して進行** **【成果】** - プロキシ起因の実行失敗を回避 - OS アップデートを実施した台数10台

### プロジェクト経験概要 大手エネルギー系企業が新規利用する SAP サーバー向けのネットワークを設計・構築した案件。**PL（プロジェクトリーダー）として設計と実装を担当**し、顧客折衝、AWS の TAM との方針すり合わせ、SAP 社担当との調整、運用引き継ぎまでを主導した。約2ヶ月の短期案件だったが、**期限より1週間早く成果物の提供まで完了** させた。 ### チーム情報 - 私の役割: **PL 兼 設計・実装担当**。メンバー中の最年少だったが、プロパーへの指示出しと成果物共有を主導 - 連携先: 顧客、AWS の TAM（Technical Account Manager）、SAP 社担当者、運用引き継ぎ先（〈要記入: チーム人数〉） - 使用技術: AWS（EC2 / SAP、Transit Gateway、Network Firewall、Route 53、Direct Connect） ### 開発・実装内容A: マルチリージョン構成のネットワーク設計と合意形成 **【概要】** リージョン障害時にもサービスを継続できるネットワーク経路を設計し、顧客合意を得たうえで実装に着手した。 **【どのような機能の開発・実装か】** EC2（SAP）、Transit Gateway、Network Firewall、Route 53 を用いたアーキテクチャを設計。複数リージョンへのネットワーク経路を用意し、リージョン障害時でもサービスを継続できる構成とした。 **【課題・問題点】** - SAP の基幹システムであり、リージョン障害がそのまま業務停止につながる - 約2ヶ月の短期間かつ緊急性が高く、設計の手戻りが許されなかった - メンバー中の最年少であり、顧客・TAM・SAP 社・プロパーという立場の異なる関係者を動かす必要があった **【打ち手・使用した技術】** - 本案件に技術アドバイスとして参加していた **AWS の TAM と定期的に打ち合わせ、設計方針をすり合わせてから顧客合意を取る順序** にし、実装着手後の手戻りを防いだ - 顧客との折衝、メール・打ち合わせでのコミュニケーションを**率先して担当** - Transit Gateway の作成時には実施日と作成リソース情報の共有が必要だったため、**SAP 社担当とのメイン窓口を務めた** - 社内ネットワークからの接続要件に対し、Direct Connect の契約手続きも遂行 **【成果】** - **期限より約1週間前倒しで成果物を提供**（〈要記入: 当初期限と実績の日付〉） - 〈要記入: 設計の手戻り件数、または顧客からの評価〉 ### 開発・実装内容B: Inspection VPC による通信の集約検査 **【概要】** どのリージョン向けの通信も必ず検査を通過する構成を作り、不要なアクセスを排除した。 **【どのような機能の開発・実装か】** Inspection VPC を独立して作成し、その中に Network Firewall を配置。行き・帰りのどちらの経路でも必ず Firewall を経由するようルーティングを設定した。 **【課題・問題点】** - マルチリージョン構成では経路が増え、リージョンごとに個別にフィルタを設けると設定漏れが発生しやすい - 戻りの経路が検査を迂回すると、非対称ルーティングによって検査自体が意味をなさなくなる **【打ち手・使用した技術】** - 検査点を各リージョンに用意した**Inspection VPC(Network Firewallが存在) 1箇所に集約**。必ずどちらかのリージョンのInspectionVPCを経由する構造にした - 行き・帰りの双方が同じ Firewall を通るようルーティングを設計し、非対称経路を作らないようにした(TGWの機能) - TGWのアタッチメント専用のサブネットを新規作成した **【成果】** - 非対称性による通信エラーの発生はなく、正常に通信できた ### 開発・実装内容C: ネットワーク非専門の運用者への引き継ぎ **【概要】** 運用を引き継ぐ担当者がネットワークの知見を持たなかったため、仕組みの解説を含む引き継ぎ資料を作成した。 **【どのような機能の開発・実装か】** Transit Gateway の仕組みと設定内容の解説を含む引き継ぎ資料を作成した。 **【課題・問題点】** - 運用引き継ぎ先の担当者がネットワークの知見に乏しく、設定値だけを渡しても運用判断ができない状態だった **【打ち手・使用した技術】** - 設定値の一覧ではなく、**Transit Gateway が何をしているかの仕組みから説明する構成**の資料を作成し、設定変更の可否を自力で判断できる状態を目指した **【成果】** - 期限内にPJを完遂し、瑕疵もなくクローズできた。

### プロジェクト経験概要 不動産会社が他社ベンダーと資料をやり取りするための接続元EC2 ,接続先ファイルサーバーを構築した案件。S3 と AWS Transfer Family を用いたセキュアな構成を設計・構築し、名前解決の問題に対してコストをかけない解決策を選択した。 ### チーム情報 - 体制プロパー5名(SAP3名、インフラ2名)、見積もり・設計・メイン実装・PLを担当。 - 使用技術: AWS（S3、Transfer Family、VPC / セキュリティグループ、VPC エンドポイント、Systems Manager Fleet Manager、Route 53 Resolver インバウンドエンドポイントを検討）、Active Directory、Windows Server、DataSpider（外部ベンダー利用） ### 開発・実装内容A: 外部ベンダーと接続するセキュアなファイル授受基盤 **【概要】** 外部ベンダーとのファイル授受を、接続元を限定した構成で実現した。 **【どのような機能の開発・実装か】** データ保存先を S3 とし、AWS Transfer Family を VPC 内に作成。セキュリティグループで特定 IP からのみ接続可能な構成とした。外部ベンダーが利用する DataSpider から S3 へデータ取得する要件に対しては、必要最小限のバケットポリシーを設計した。 **【課題・問題点】** - 社外のベンダーがアクセスする基盤であり、意図しない範囲へのアクセスを許すと情報漏洩につながる - 一方で DataSpider からの取得は許可する必要があり、単純に閉じるだけでは要件を満たせなかった **【打ち手・使用した技術】** - Transfer Family をパブリックではなく **VPC 内に作成** し、セキュリティグループで接続元 IP を限定 - バケットポリシーで DataSpider からの取得経路のみを許可し、許可範囲を要件ちょうどに絞った **【成果】** - 運用開始後のセキュリティインシデントゼロ ### 開発・実装内容B: AD 環境下での名前解決問題をコストゼロで解決 **【概要】** 標準的な解決策がオーバースペックかつ高コストだったため、環境の制約を踏まえた別解を選択した。 **【どのような機能の開発・実装か】** Fleet Manager を利用する想定で VPC エンドポイントを作成したが疎通せず、**原因を切り分けて代替手段を選定**した。 **【課題・問題点】** - DNS が Route 53 ではなく Active Directory を使った環境であり、VPC エンドポイントを作成しただけでは名前解決ができず接続元となるEC2へ構築担当者(クラウドベンダ)が接続できなかった - Route 53 Resolver のインバウンドエンドポイントを利用することで名前解決は可能になるが、**毎月の固定コストが発生** する - 接続元サーバーが少なくサービスも小規模なため、インバウンドエンドポイントは明らかにオーバースペックだった **【打ち手・使用した技術】** - 「技術的に正しい解」と「この規模に見合う解」が一致しないと判断し、**規模に対する妥当性を基準に代替案を検討** - 接続元サーバーが少数である点を踏まえ、**Windows の hosts ファイルに IP を直接記載する方式を採用**し、追加コストゼロで名前解決を実現 **【成果】** - **Route 53 Resolver インバウンドエンドポイントの代わりにWindowsのHostsファイルをへ直接記載することで月額コストをゼロに抑えたまま要件を充足**

### プロジェクト経験概要 大手薬局チェーンの Web サイトリニューアルにおいて、リダイレクト機構の設計・検証・実装・運用保守を担当した。**作業の大部分をメインで遂行**し、並行してプロパーへの情報共有と育成も行った。外部ベンダーが多数関わる大規模プロジェクトだった。 ### チーム情報 - 私の役割: AWS領域におけるテックリード・実装を担当。（リダイレクト機構の設計・検証・実装・運用保守）。一部プロパーへの情報共有・育成を兼務 - 連携先: 顧客１社、外部ベンダー１０社ほど - 使用技術: AWS（CloudFront、CloudFront Functions、ALB、Lambda@Edge を検討）、外部 DNS サービス(IIJ DNSプラットフォームサービス) ### 開発・実装内容A: CloudFront Functions によるリダイレクト機構 **【概要】** ALB の標準機能では実現できないリダイレクト要件に対し、構成そのものを提案し直して実装した。 **【どのような機能の開発・実装か】** リダイレクト要件をヒアリングし、当初構成に存在しなかった CloudFront を間に挟む構成を **提案**。リダイレクト処理を CloudFront Functions で実装した。 **【課題・問題点】** - サーバーをリニューアルするが、利用者が叩く URL は変えずに内部でリダイレクトする要件だった - ヒアリングの結果、**単純な ALB のリダイレクトでは対応できないパスパターンが複数存在** することが判明した - 当初の構成には CloudFront が含まれておらず、構成変更の提案が必要だった **【打ち手・使用した技術】** - 要件を満たせないことを実装前のヒアリング段階で特定し、**CloudFront を追加する構成変更を提案** - 実装方式は CloudFront Functions と Lambda@Edge を比較し、**構築難易度・処理速度・運用負荷の3軸で評価して CloudFront Functions を採用** - 採用理由を整理したうえで合意を取り、設計・検証・実装・運用保守まで担当 **【成果】** - 対応したリダイレクトのパスパターン数:10 ### 開発・実装内容B: DNS 切り替えリスクの事前検知と回避 **【概要】** 外部 DNS サービスの仕様を事前調査し、リリース当日に発生するはずだったトラブルを未然に防いだ。 **【どのような機能の開発・実装か】** 顧客が管理する外部 DNS サービスのレコード値を CloudFront 向けに書き換える必要があったため、**DNS サービスの仕様を調査**し、切り替え手順を設計した。顧客は DNS の知見が少なかったため、作業手順と設定内容の共有・サポートも実施した。 **【課題・問題点】** - 当該 DNS サービスは **レコードの修正は即時反映されるが、レコードの新規登録は反映に1日以上かかる** 仕様だった - この仕様を知らずにリリース当日に新規登録を行うと、切り替えが完了せず当日のリリースが失敗する構造だった - 顧客側に DNS の知見が少なく、顧客側でこのリスクを検知できる見込みがなかった **【打ち手・使用した技術】** - **仕様を事前に調査して反映遅延を特定** し、「当日は修正のみで済む状態」を作るため、**レコードの事前登録を提案** - 顧客向けに作業手順と設定内容を共有し、DNS 作業を安全に実施できるようサポート **【成果】** - **リリース当日のトラブルを未然に回避し、切り替えに成功** - ダウンタイム:数分程度、夜間メンテナンス期間に実施したためユーザ影響なし ### 開発・実装内容C: 多数の外部ベンダーとの横断調整 **【概要】** 関係ベンダーが多い大規模プロジェクトで、作業タイミングと意図を共有する運用を回した。 **【どのような機能の開発・実装か】** 他ベンダーからの相談対応と情報共有を密に行い、各社の作業タイミングと作業意図が相互に共有される状態を作った。 **【課題・問題点】** - 顧客以外の外部ベンダーが非常に多く、各社の作業タイミングが衝突すると切り替え全体が破綻するリスクがあった - 各社が互いの作業意図を把握しておらず、調整の起点がなかった **【打ち手・使用した技術】** - 他ベンダーからの相談を受ける窓口として機能し、作業タイミングと意図を横断的に共有 **【成果】** - 大きな問題を発生させることなくプロジェクトを完遂