ID:82386さん

## プロジェクト概要 社内初のECS Fargateを採用した法務プラットフォーム向けインフラ環境を設計・構築・運用しました。 ## 役割・体制 ### 自身のポジションと役割 - インフラエンジニアとして、AWS ECS Fargateを用いたコンテナ基盤の設計、構築、運用・保守を担当しました。 - VPC設計、IAMポリシー設計、セキュリティグループ設計を一貫して実施し、インフラのコード化をTerraformで推進しました。 - CI/CDパイプラインの構築により、アプリケーションチームの運用負荷軽減を実現しました。 ### チーム規模と構成 - インフラ担当の2名チームで、社内初のECS Fargate環境構築を主導しました。 - 小規模ながら密なコミュニケーションを図り、設計から運用まで柔軟に対応しました。 ## 背景・課題 - 法務プラットフォームの安定稼働とスケーラビリティ確保のため、AWSのマネージドコンテナサービスECS Fargateによるインフラ刷新が必要でした。 - 参考となる既存環境がなく、特にプライベートサブネット内でAWSのエンドポイントを適切に利用する設計に苦労がありました。 - プライベートサブネットのネットワーク構成に伴うセキュリティと通信要件の両立が課題でした。 ## 実際の取り組み ### 開発環境 - AWSを中心に、ECS Fargateを用いたコンテナオーケストレーション環境を構築し、Cloudflareを利用してトラフィックの分散・セキュリティ強化を行いました。 - VPCの設計からIAM、セキュリティグループまで包括的に設計し、Terraformでインフラをコード化することで環境の再現性と管理性を高めました。 - CI/CDパイプラインを整備し、アプリケーションの最小限の設定でのデプロイを可能にしました。 ### 設計・改善内容 - プライベートサブネット内でAWSエンドポイントを活用するため、VPCエンドポイントの設計と実装を工夫し、セキュアな通信経路を確保しました。 - Terraformコードのモジュール化により、インフラ構成の再利用性と保守性を向上させ、運用負荷の軽減に寄与しました。 - CI/CDパイプラインを構築し、アプリケーション側の設定を簡素化するとともに、デプロイの自動化と品質向上を実現しました。 - Cloudflareの導入により、外部からの攻撃対策とトラフィック分散を強化し、サービスの安定稼働を支えました。 ### その他アピールポイント - 社内初のECS Fargate導入プロジェクトとして、ナレッジ共有資料を作成し、社内の他プロジェクトへの展開を支援しました。 ## 成果・価値 - 社内初のECS Fargate環境を安定稼働させ、法務プラットフォームの信頼性とスケーラビリティを向上させました。 - インフラコード化とCI/CDパイプラインにより、運用工数を削減し、アプリケーション開発チームの効率化に貢献しました。 - セキュアなプライベートネットワーク設計により、コンプライアンス要件を満たしつつ、高い可用性を実現しました。

## プロジェクト：EC2からEKSへの全面リプレイスと自律型開発基盤の単独構築 ### プロジェクト概要 運用の不透明さと開発サイクルの停滞を打破するため、単独でEC2からAmazon EKSへのリプレイスプロジェクトを完遂しました。技術選定から実装、運用設計までを独力で行い、少人数のエンジニア組織でもセキュアかつ迅速にアプリケーションを追加・検証できる基盤を実現しました。 ### 役割・体制 - **ポジション**: ソロ・インフラエンジニア（設計・構築・移行・運用のすべてを担当） - **体制**: インフラ担当1名（アプリ側に強いエンジニアに要件や使い勝手の相談をしつつ、実装はすべて一人で完遂） ### 背景・課題（EKS移行の動機） - **検証環境の不足**: EC2環境では手軽に環境構築ができず、プルリクエスト（PR）単位での動的な動作確認が困難だった。 - **運用の不透明性**: サーバー内の設定ファイルがGit管理されておらず、ブラックボックス化や設定ドリフトが常態化していた。 - **拡張性の限界**: 少ないエンジニアリソースで今後増加するアプリケーションを効率的に管理するため、オーケストレーションと自動化が不可欠だった。 ### 実際の取り組み #### 1. ArgoCDによるGitOps管理と「App of Apps / ApplicationSets」の導入 - **設定の可視化**: 今まで未管理だったサーバー設定ファイルをすべてGitOps管理下へ移行。 - **基盤管理（App of Apps）**: ArgoCDやIngress-NGINX等の基盤コンポーネントは、公式のHelm Chartをリポジトリから直接参照する「App of Apps」パターンで構成。運用の標準化とバージョン追随性を確保。 - **アプリ追加の自動化（ApplicationSets）**: ジェネレーターを活用し、リポジトリにディレクトリを追加するだけでインフラ作業なしに新規アプリがデプロイされる「セルフサービス型」の基盤を構築。 #### 2. PR連動型Preview環境の動的構築 - GitHub ActionsとArgoCDを連携させ、PR作成時に専用のNamespaceと動的URLを自動発行する仕組みを独力で構築。 - 開発者が「本番相当の環境」で即座にレビュー・テストを行える状態を作り、リリースサイクルを劇的に高速化。 #### 3. セキュリティ設計：IRSAによるPod単位の権限分離 - **課題**: EC2時代の広範なインスタンスプロファイルを廃止し、セキュリティを強化。 - **苦労した点**: Podごとに最小権限を与える **IRSA（IAM Roles for Service Accounts）** への移行。既存の権限を精査し、セキュリティを担保しつつアプリケーションを動かすための設定分離に最も時間を割きました。 - **解決策**: TerraformでIAM Role、Trust Relationship、ServiceAccountをパッケージ化したモジュールを作成。設定をテンプレート化することで、高度なセキュリティ設定を一人でミスのないよう維持できる構成にしました。 #### 4. ハイブリッドな監視基盤の構築 - **CloudWatch**: AWSリソースおよびログ管理（Container Insights）。 - **Grafana + Prometheus**: Podの詳細なリソース使用状況を可視化。一人で全レイヤーの異常を検知できるよう、カスタムダッシュボードを整備。 ### 成果・価値 - **開発速度の向上**: Preview環境の導入により、QA・レビューの並列化を実現。 - **運用の効率化**: GitOpsへの移行により、設定変更の履歴が明確になり、インフラ担当の手を借りずともアプリエンジニアが自律的にデプロイできる環境を構築。 - **高い信頼性とセキュリティ**: IRSAによる厳格な権限分離と、公式イメージをベースとした構成管理により、セキュアでメンテナンス性の高い基盤を実現。

# AWS WAF移行プロジェクト：セキュリティ運用の内製化と最適化 ## 1. プロジェクト概要 既存の外部WAFサービス「攻撃遮断くん」から、AWS WAFへのリプレイスを全工程（設計・構築・移行・運用）一人で担当。 コスト削減、最新プロトコル対応、およびセキュリティ運用の機動性向上を実現。 ## 2. 背景と課題 - **コストの最適化:** 固定費の高い外部サービスから、トラフィックに応じた従量課金のAWS WAFへ移行し、ランニングコストを抑制する必要があった。 - **技術的負債の解消:** 旧環境ではHTTP/2.0への対応が難しく、モダンなフロントエンド表示速度のボトルネックとなっていた。 - **運用のブラックボックス化:** セキュリティルールがベンダー管理だったため、誤検知発生時の調査やルール調整に時間がかかり、エンジニア主導の迅速な対応が困難だった。 ## 3. ソリューション構成 - **WAF本体:** AWS WAF (ALB / CloudFront適用) - **ルール管理:** WafCharm（Cyber Security Cloud社）の導入 - マネージドルールによる運用自動化と、エンジニアによる詳細制御の両立。 - **分析基盤:** AWS CloudWatch Logs - リアルタイムなログ分析による誤検知の迅速な特定。 ## 4. 実施内容 ### ① 移行計画と環境構築 - **WAFのプロビジョニング:** AWSマネジメントコンソールを用いた環境構築。 - **WafCharm連携:** シグネチャの自動更新設定および通知フローの構築。 ### ② DNS切り替えとプロトコル刷新 - **DNS Record変更:** CNAME/Aレコードの切り替えを伴う移行作業の完遂。 - **HTTP/2.0有効化:** 移行に合わせてプロトコルをアップグレードし、通信の多重化によるパフォーマンス向上を実現。 ### ③ 徹底した誤検知（False Positive）対応 - **カウントモードによる検証:** 本番適用前に一定期間カウントモードで運用し、正当なリクエストがブロックされないかログを全件精査。 - **例外ルールの定義:** 業務上必要な特定パスやAPIへのリクエストに対し、個別に除外設定を行い、可用性とセキュリティのバランスを最適化。 ### ④ 運用体制の変革 - **エンジニア主導のセキュリティ:** ブラックボックスだったルールセットを可視化し、エンジニアが直接CloudWatch Logs等を確認して判断・修正できる体制を構築。 ## 5. 主要な成果 | 項目 | 成果内容 | | :--- | :--- | | **コスト削減** | 月額固定費の大幅な抑制（従量課金＋WafCharmの最適化） | | **パフォーマンス向上** | HTTP/2.0対応によるサイトレスポンスの改善 | | **運用の俊敏性** | 誤検知対応を含むセキュリティ判断を内製化し、対応リードタイムを短縮 | | **技術的オーナーシップ** | インフラ構成の一部としてセキュリティを管理下に置くことに成功 |

# 大規模DDoS攻撃対応プロジェクト：230億リクエストの防御とコスト最適化 ## 1. 概要 1週間にわたり発生した世界規模の分散型DDoS攻撃（総リクエスト数：約230億件）に対し、インフラ全般の防御指揮および実務を完遂。 AWS WAFを用いた高度なトラフィック分析による攻撃者特定から、最終的には課金爆発を防ぐためのCloudflareへの緊急移行までを独力で実施。 ## 2. インシデントの規模と背景 - **攻撃規模:** 1週間で約230億リクエストという極めて大規模なDDoS。 - **攻撃元:** 世界中から分散されたボットネットによるリクエスト。 - **課題:** - サービス停止の回避。 - 大量のリクエスト処理およびログ出力に伴う、CloudWatch等のAWSコストの急騰（課金爆発の阻止）。 ## 3. 対応プロセス（フェーズ別） ### フェーズ1：AWS WAFによる暫定防御 - **初期対応:** - 特定IPのレートリミット制限の適用。 - 明らかに不要な国・地域からの海外アクセスブロック。 - **限界:** IP分散型の攻撃であったため、IPベースの遮断だけでは決定打に欠け、リクエスト処理自体によるコスト増が課題となった。 ### フェーズ2：JA4 Fingerprintを用いた攻撃者の特定（技術深掘） - **詳細分析:** WafCharm（Cyber Security Cloud社）のサポートと密に連携し、攻撃トラフィックのログを精査。 - **特定:** TLSクライアントの特性を識別する「**ja4_fingerprint**」が、世界中からの攻撃リクエスト間で一致していることを突き止めた。 - **精密遮断:** IPアドレスに関わらず、特定のja4_fingerprintを持つリクエストをAWS WAFでピンポイントにブロックするルールを構築。これにより誤検知を最小限に抑えた防御を実現。 ### フェーズ3：Cloudflareへのリプレイスによるコスト最適化 - **意思決定:** AWS WAFでのブロックを継続した場合、CloudWatch Logsやメトリクスの従量課金が数千万円規模に達するリスクを予見。 - **実行:** - DDoS耐性が標準で極めて高く、エッジでのブロックコストが抑えられるCloudflareへの移行を決定。 - DNS切り替えを含む全トラフィックの移行を緊急実施。 - **結果:** セキュリティ強度を落とすことなく、インフラ課金額を劇的に抑制することに成功。 ## 4. 成果 | 項目 | 成果内容 | | :--- | :--- | | **可用性の維持** | 230億件の攻撃下においても、正当なユーザーのアクセスを維持しサービス継続に成功。 | | **コスト削減** | AWS WAF/CloudWatchの超過課金を回避。Cloudflareへの移行により予測可能なコスト構造へ改善。 | | **技術的オーナーシップ** | ja4_fingerprintを用いた最新のフィンガープリント解析による高度な防御手法を確立。 | | **少数精鋭での完遂** | 2名という最小限の体制で、24時間体制の監視・分析・移行作業を完遂。 |

# 監視・ログ運用基盤の抜本的改善プロジェクト ## 1. 概要 監視・アラートが未設定だった30台超のEC2および6台のRDSに対し、一括導入スクリプトを用いた監視基盤を構築。 あわせて、ディスク逼迫の根本解決（Logrotate/S3退避）と、アプリケーションログの構造化（Lograge）によるパフォーマンス分析環境を実現。 ## 2. 背景と課題 - **可視性の欠如:** アラート設定がなく、サービス停止まで異常に気付けない受動的な運用。 - **ディスク容量の脆弱性:** ログローテートの仕組みがなく、ログ蓄積によるディスクフルが常態化。 - **分析困難なログ:** 生のテキストログが非構造化データとして出力されており、DB処理やレスポンス時間のボトルネック特定が困難だった。 ## 3. 実施内容 ### ① 監視自動化スクリプトの作成と一括配備 - **自動導入スクリプトの開発:** CloudWatch Agentのインストール、設定（CPU/Memory/Disk/Network等）、起動を完遂するスクリプトを作成。 - **大規模展開:** 30台以上の本番EC2に対し、スクリプトを用いて一括で監視環境を構築し、作業工数の削減と設定の標準化を実現。 ### ② ログ管理戦略の刷新（ストレージ最適化） - **Logrotateの導入:** 全サーバーにLogrotateを配備し、ディスク容量90%超過などのアラート発生を未然に防ぐ仕組みを構築。 - **ライフサイクル設計:** 古いログは順次S3へアップロード・退避させる構成とし、ストレージコストの最適化と長期保存を両立。 ### ③ Lograge導入による可観測性の向上 - **ログの構造化:** Ruby on Railsの `lograge` gemを導入。肥大化しがちな生のログを、必要な情報（Duration, View, DB, Status等）に絞ったJSON形式等の構造化ログに変換。 - **パフォーマンス分析:** CloudWatch Logs Insightsを活用し、DB処理時間や全体のレスポンスタイムをクエリで即座に分析・可視化できる環境を整備。 ## 4. 成果 | 項目 | 成果内容 | | :--- | :--- | | **予防保守の実現** | サービス停止前にアラート（Slack通知）で検知し、未然に対処可能な体制へ移行。 | | **ストレージ安定化** | ログローテートとS3退避により、ログ起因のディスクフル障害をゼロに。 | | **ボトルネック特定** | Logrageにより、APIレスポンスの遅延原因（DBクエリ等）を数値ベースで特定可能に。 | | **運用効率化** | スクリプトによる一括管理で、新規サーバー追加時の監視設定コストを大幅削減。 |

# Railsアプリケーション：データ駆動型パフォーマンス改善プロジェクト ## 1. 概要 構築済みのCloudWatch監視基盤（Lograge構造化ログ）を活用し、DB負荷の高いページを特定。 クエリのN+1問題解消およびSQLの最適化を実施した結果、対象ページのレスポンス速度を40%改善。 ## 2. 背景と課題 - **レスポンス遅延の顕在化:** 特定の主要ページにおいて、アクセス増加時にDB CPU使用率が高騰し、ユーザー体験を損なう遅延が発生していた。 - **原因特定の困難さ:** Rails標準ログでは各クエリの処理時間が分散しており、どの処理が全体を圧迫しているかの定量的判断が難しかった。 ## 3. 実施内容 ### ① ボトルネックの定量分析（CloudWatch Logs Insights） - **データ抽出:** `Lograge` で出力した構造化ログをCloudWatch Logs Insightsで解析。 - **特定:** `db_runtime`（DB処理時間）が異常に長いエンドポイントをランキング化し、修正優先度の高いページを特定。 ### ② クエリのN+1問題の解消 - **コード監査:** Railsの `includes`, `preload`, `eager_load` を適切に使い分け、関連レコードの一括取得（Eager Loading）を実装。 - **改善:** 1ページ表示につき数百回発行されていたSQLクエリを数回に集約。 ### ③ SQLおよびインデックスの最適化 - **実行計画（EXPLAIN）の分析:** 重いクエリに対してEXPLAINコマンドを実行し、フルテーブルスキャンの発生を確認。 - **インデックス設計:** 検索条件（WHERE句）やソート（ORDER BY句）に利用されるカラムに対し、適切なインデックスを追加。 - **クエリのリライト:** RailsのActiveRecordメソッドを調整し、より効率的なSQLが発行されるようリファクタリングを実施。 ## 4. 成果 | 指標 | 改善前 | 改善後 | 変化率 | | :--- | :--- | :--- | :--- | | **平均DB処理時間** | (例) 500ms | 300ms | **40% 削減** | | **最大レスポンスタイム** | 顕著な遅延あり | 安定した応答 | 大幅な安定化 | | **DBサーバー負荷** | CPU高負荷を記録 | 低負荷で安定稼働 | リソース効率向上 |