Makoto Taguchi

# プロジェクト概要 - 人材系サービスのファーストリリースに向けた開発とインフラ整備 # 期間・規模 - 2022/9 ~ 2023/3 - チーム内：9名（マネージャー1名、バックエンド/インフラ4名、フロントエンド4名） - 機能ごとにチーム分かれており、他チームのエンジニアとのやりとりもあり - プロジェクト全体：企画・デザイナー含め50名程度 # 担当 - バックエンドの開発 - GCPインフラの構築・運用改善 # 使用技術 ## 開発関連 - NestJS, TypeScript, MySQL, Jest, Prisma - Docker, MySQL WorkBench, Swagger, Postman ## インフラ関連 - GCP（GKE, CloudRun, GCE, CloudSQL, LB, CloudArmor, VPC, GCS, Pub/Sub, Cloud Build等） - Terraform, Datadog, Kubernetes, GitHub Actions # 担当業務 - バックエンド - API実装 - DB論理設計 - e2eテスト/ユニットテスト作成 - インフラ - GCPインフラの構築、改善（Terraform記述） - GKE運用（K8sマニフェスト作成等） - アーキテクチャ図の作成 - 深夜のファーストリリース作業 # 工夫した点 - インフラ領域では、AWSの設計構築経験があったこともあり、GCP初経験ながらも既存インフラのterraform化、セキュリティ強化（権限の最小化、通信の制限等）、コスト最適化、GKE/CloudSQLバージョンアップ等を提案し幅広く運用改善に貢献した。 - 開発領域では、業務外の学習を特に心がけ、いちはやキャッチアップし、API開発・テストコード作成だけでなくDBの設計やコードのリファクタリングにも貢献した。 - 拡張性を常に意識した。期日が短いながらもリファクタリングやより良いDBテーブル設計についてファーストリリース前の影響が少ない段階でできるだけ対応しておくべきと考え、前向きに対応した。 - できるだけ多くのメンバーが見てわかる文書の作成を自発的に行なった。例えば、 - DB論理設計はバックエンドエンジニアであればDDLで理解できるが、デザイナーや委託先も見る場合があったため、補足説明も記載したスプレッドシートのDB定義書を作成した。 - インフラ構成は、開発エンジニアが大半でインフラ領域に詳しいエンジニアが少なかったたこともあり、参画時の段階でアーキテクチャ図があまり整備されていなかった。そこで自発的に図を詳細化してミーティングで説明するなどして、インフラ担当者以外でも全体の構成や通信の流れを把握できるようにしてチーム全体の理解度を上げた。

# プロジェクト詳細 ## 課題 - インフラ設計構築チームでは、CloudFormationでのテンプレート管理を行っていた。 - テンプレート数や、チームの人数が増えてきたため、従来のPMによるプルリクのレビューだけでは品質維持が難しくなってきている背景があった。 - そこで、今後のチーム規模拡大に向けテンプレートの品質を維持すべくCIパイプラインによる自動テストを導入することとなった。 ## CIパイプラインの内容 - GitHubリポジトリ（汎用テンプレート管理用）devブランチへの、プルリクエストのマージをトリガーに、自動テスト - テスト内容 - 静的解析（cfn-lint） - CFnルートスタックの検証環境へのデプロイ確認 - Teamsチャネルへのテスト結果通知 # 担当 - CIパイプラインの検証・構築・実運用への導入 # 使用技術 - AWS（CloudFormation, CodePipeline, CodeBuild, CodeStar, Lambda, S3, IAM, SNS） - Github Enterprise Server, cfn-lint - VSCode, AWS Cloud9 # 担当業務 - GitHubフローによるブランチ運用方法の調査 - AWS Codeシリーズ利用事例の調査 - AWSアーキテクチャ設計 - AWS利用料の見積り（ビルドにかかる料金等） - CIシステムの構築（CloudFormation） - 実運用への導入 - 運用方法についてチームメンバーとの議論 # 工夫した点 -運用でなるべく手間がかからないよう意識し、下記の機能を持ったLambda関数を作成した。 - Teamsへのテスト結果通知時に、失敗時のみメンション（成功時はメンションしない）するようにし、被通知者の確認工数を減らす。 - ルートスタックの作成後、作成したS3バケット中のオブジェクトを全削除した上でルートスタック削除する構成とし、スタック削除エラーを回避。 - 既存のブランチ運用のままでは、CIシステムのアーキテクチャが複雑となり、システム全体の理解や修正が煩雑になる恐れがあったため、一般的なGit運用方法を調査しGitHubフローに則った運用を提案した。結果自分の提案が採用され、CIシステムもシンプルなものとなり後々負債となる可能性を回避できた。 # アピールポイント - DevOps系のスキル AWS上でのCIパイプラインの構築スキル、Gitリポジトリの運用方法（フロー）の理解や、チームメンバーとの議論による最適なCI構成の検討など、従来のクラウドインフラ設計構築だけでは経験できないことができ、DevOpsの理解が深まった。

# プロジェクト概要 - EKSを含むAWSインフラの設計構築（EKS on EC2） # 使用技術 - AWS（EKS, CloudFormation, IAM, VPC, VPC Endpoint, ALB, EC2, S3, ECR, RDS Lambda, KMS, SecretsManager, Route53, ACM, WAFv2, Inspector v2） - VSCode, Docker, AWS CloudShell, FluentBit # 工夫した点 - 現場でも初めての試みであるEKSの設計構築を担当させていただいた。ログの永続化やオートスケーリング・EKSの操作権限管理・構成管理の分離など、本番運用に向け考慮すべき事項が多数ある中、利用者とQA表によるやりとりで要件を明確化し、実現に向けてつまづく箇所はAWSサポートへの問い合わせ等で解決策して無事インフラ構築と引き渡しを完了した。 - 取り組み詳細の一例は以下Qiitaに投稿しています。 - EKS on EC2の本番運用に向けて考えたこと https://qiita.com/MAKOTO1995/items/6ef1d55850a3511147a5 - CFnとK8sマニフェストの構成管理の区分け https://qiita.com/MAKOTO1995/items/caa951c45ee119e70a60

# プロジェクト概要 - 複数プロジェクトでのAWSインフラ設計構築 # 使用技術 - AWS（CloudFormation, IAM, VPC, EC2, S3, CloudFront, ECS, ECR, RDS, RDSProxy, Lambda, KMS, SecretsManager, Codeシリーズ, Route53, ACM, API Gateway, NLB, WAFv2, Inspector v2） # 取り組み - 利用者や開発チームの提示する機能要件・非機能要件に基づいたAWSインフラのアーキテクチャ設計 - AWS利用料の見積り - 基本設計書、パラメータシートの作成 - 構築（主にCloudFormationを記述してデプロイ） - AWSサービス間の結合テスト、機能テスト - AWSサポートへの不明点問い合わせ # 工夫した点 - それまで手動管設定していた構成をCFnテンプレート化してチームに導入し、別案件でも汎用的に使いまわせるようにしてインフラ構築省力化に貢献した。（Route53のエンドポイントヘルスチェック、ECR脆弱性スキャン結果のメール通知など） - 引き合いから構築完了・引き渡しの期限が短いイレギュラー案件もあったが（開発・プロダクション環境2面を1ヶ月弱）、自らマイルストーンを作成し日次で上長に進捗報告/不明点の相談など行い主体的に業務を進めたことで、無事引き渡し完了できた。 　これにより現場でも一定の信頼をいただき、別のEKS案件を担当させていただけることとなった。