ID:77169さん

# プロジェクト概要 ## 目的・背景 複数のAWSアカウント・リージョンで運用するクラウド基盤について、手作業や手順書に依存した運用が多く、構成管理の複雑化や属人化、変更作業の負荷が課題となっていた。 SREとして、インフラのIaC化、CI/CDによるデプロイ自動化、クラウドコストの最適化、アクセス権限やセキュリティの見直しなどを通じて、クラウド基盤の標準化・運用効率化・保守性向上を推進した。 特に、複数アカウント・複数リージョンへ展開されているAWS環境について、Terraform / Terragruntを用いたIaC管理基盤の整備や、Lambdaをはじめとする既存システムのデプロイプロセス自動化に取り組んだ。 ## 規模感・チーム構成・担当した役割 * 開発チーム：約20名 * SREチーム：3名 * 役割：SREメンバー * AWSアカウント数：約9 * 対象リージョン数：4リージョン * 主に東京リージョンへ集中 # 取り組んだ課題 ## 1. マルチアカウント・マルチリージョンAWS環境のIaC化 ### どんな課題だったのか 既存AWS環境は手動で構築されたリソースが多く、構成変更や新規環境への展開時に手作業が必要だった。 AWS約9アカウント、4リージョンを管理する必要があり、単純にTerraformコードを環境ごとに複製すると、重複コードが増加し、設定変更時の修正漏れや保守コストの増大が懸念された。 また、既存リソースをIaC管理へ移行するため、実際のAWS環境を調査しながらTerraformコードおよびimport処理を整備する必要があった。 ### 技術的なアプローチや工夫した点 Terraformの共通化と環境差分の管理を行いやすくするため、Terragruntを採用した。 Terragruntのディレクトリ構成については、AWSアカウント・リージョン・コンポーネント単位で管理できる構成を設計し、共通設定の重複を抑えながらマルチアカウント・マルチリージョンへ展開できる形とした。 既存環境のIaC化では、ClaudeやCodexにReadOnlyAccess相当の権限でAWS環境を調査させ、既存リソースに対応するTerraformコードやimport用コードの生成を補助させた。 その後、Terraform planで実環境との意図しない差分がないことを確認しながら段階的に管理対象へ移行した。 ### 取り組みの成果 AWS約9アカウント、4リージョンにまたがる既存AWS環境について、Terraform / Terragruntを利用したIaC管理基盤を整備した。 移行に合わせて不要設定やリソースを見直し、コスト最適化やセキュリティ改善も並行して実施した。 ## 2. Lambdaデプロイ基盤の自動化 ### どんな課題だったのか 各AWSアカウントには数十程度のLambdaが存在していたが、従来はCLIと手順書を用いた手動デプロイを行っていた。 この運用では、作業者による手順差異や操作ミスが発生する可能性があり、Lambda数や対象アカウントが増えるほど運用負荷も大きくなるという課題があった。 また、多くのLambdaが長期間更新されておらず、利用しているPythonランタイムがAWS上で非推奨となっているものも存在していた。 そのため、ランタイム更新への対応と今後の保守性向上を目的として、Lambdaのコンテナイメージ化とCI/CDによるデプロイ自動化を実施した。 ### 技術的なアプローチや工夫した点 Lambdaのデプロイ方式をコンテナイメージ方式へ移行し、DockerイメージをECRへPushした上で、Lambdaおよび関連リソースをTerraformで一元管理する構成とした。 GitLab CI/CDでは、以下のパイプラインを構築した。 1. Gitのコミット差分から変更対象のLambdaを自動検出 2. 対象Lambdaにテストディレクトリが存在する場合のみ単体テストを実行 3. Lambda用Dockerイメージをビルド 4. Amazon ECRへイメージをPush 5. Terraformによるplan / applyを実行 複数のLambdaを効率的に処理するため、GitLab CI/CDのparallel matrixを利用し、変更されたLambda単位でテスト、ビルド、デプロイを並列実行できるようにした。 また、Lambdaの設定値にはAWSアカウント・リージョンごとの差分が存在したため、以下のような命名規則によるtfvarsファイルを利用して環境差分を分離した。 `<account-name>-<region-name>.tfvars` これにより、Terraformコード本体の共通化を維持しながら、Lambdaの環境変数など、アカウント・リージョン固有の設定を管理できる構成とした。 ### 取り組みの成果 既存Lambdaについては約8割をTerraform管理下へ移行した。 従来はCLIと手順書によって実施していたLambdaのデプロイ作業について、テスト、Dockerイメージのビルド、ECRへのPush、TerraformによるデプロイまでをGitLab CI/CDで自動化し、関連する手作業をほぼ削減した。 また、コミット差分によるデプロイ対象の自動判定とparallel matrixによる並列処理を導入し、複数Lambdaが存在する環境でもパイプライン全体を数分程度で完了できるようにした。 ## その他に取り組んだ課題 * RI / Savings Plansの導入によるAWSコスト最適化 * 開発者に対するインフラ構築・運用支援 * 定期リリースプロセスの改善、CI/CD導入 * IAM Identity Centerの導入およびIAM権限の棚卸し * 新規サービス向けAWSインフラの構築（S3 / CloudFront / ECS / RDS） * GKEステージング環境の構築自動化、および定期リリースの半自動化による属人化の解消 * 約30台のAmazon RDS for MySQLを対象に、MySQL 8.4へのメジャーバージョンアップ対応を実施 * 既存のマイナーバージョンアップ手順書をベースに、メジャーバージョンアップ特有の互換性影響や追加確認事項を整理 * MySQL 8.4のリリースノートやAWS公式ドキュメントを確認し、非推奨・削除機能、仕様変更などのアプリケーション／DBへの影響を調査 * 2名体制のうち主担当として、調査方針の整理、検証、手順の実施を中心に担当

# プロジェクト概要 私は農業系組合の情報システム部門に派遣され、ADやM365などのシステム運用業務を行なっています。 外部ベンダーが設計・構築したAzure OpenAIを用いたチャットサービスが派遣先の親会社向けに既に存在しています。 今回、それとほぼ同じ環境を派遣先でも構築することになりました。 今後のグループ会社展開を見据えて、IaCを用いた内製化をすることになりました。 派遣先にAzure構築やIaCのナレッジがなかったため、ベンダーと共に親会社向け環境を参考に構築しました。 # 体制 私とプロパーでベンダーに直接赴き、2名のベンダーの技術者との計4名でAzure環境の構築と運用設計を2週間で行いました。 # 課題 1. 親会社向け環境自体にセキュリティの不備 2. デプロイ方法の未整備 3. AzureやTerraformのナレッジ不足 # 解決方法 1. APIキーのKey Vault利用 IP制限などの見直し 2. 派遣先にGitHub環境がなかったため、PowerShellスクリプトにてデプロイ 3. Azure資格取得を通した自己学習やエンジニアコミュニティのTerraformの課題で学んだことを活用 (Terraformのoutputを用いて構築手順を簡略化する提案など) # 工夫 デプロイ方法はGitHub Actionsを導入しようとしていましたが、派遣先がGitHubも使っていない環境でした。 そのためPowerShellスクリプトによるデプロイ方法を準備し、そちらをメインとしました。 構築後の現在、派遣先メンバと相談しTerraformのコード管理にGitHubを使えるかは検討中となります。 GitHub Actionsについてはまず開発環境で試し、慣れてきたら本番でも導入する予定です。 上記の決め事をベンダーと派遣先の間に立って積極的に疑問点を潰すコミュニケーションを取ることができました。 # 成果 ベンダーと協力してシステム構築をするという特殊な事例でしたが問題なく構築できました。 同行したプロパーにTerraformやPowerShell、VSCodeでのコーディング力などをお褒め頂きました。 内製化のためのナレッジ蓄積も行うことができました。 # Azure使用リソース * Azure App Service * Azure OpenAI * AI Search * Bing Search * CosmosDB * BLOB Storage * Azure Key Vault # Terraformの構成 * おおむねリソースごとにモジュール化 * モジュール化した単位でtfstateを分けて管理 * tfstateはBLOBストレージにて管理

# プロジェクト概要 2023/06~ 農業系組合の情報システム部門へ派遣 主にADやM365などのシステム運用業務 # 自社チームリーダー 2024/07~ 2024年7月から自社の派遣先のチームリーダーに就任 月次でチームメンバーとの1on1を実施 1on1で分かった自社メンバからのフィードバックや今後の案件、人員調整について話し合う定例を派遣先の課長と月次で実施 ほかには月末にメンバーの勤怠表のチェックなど自社提出物の管理や社内勉強会(Azure)の講師を実施 # 主な業務内容 * 人事異動に伴うユーザー登録・削除 * 問い合わせ対応 * 障害対応 * ベンダ問い合わせ(障害対応・技術調査) * 月次稼動レポート、お客様向け維持管理報告書作成 * 手順書作成・修正(ユーザ向け手順書・運用手順書・簡単な構築手順書) * 検証・設定変更(グループポリシー・PowerShellスクリプト・レジストリなど) * 認証システム変更に伴う受け入れテスト テスト仕様書に沿って変更後に想定の画面遷移になるか確認 * Gmailガイドライン変更に伴う対応 メールシステム構成図作成やSPF・DKIM・DMARCなどのDNSレコードについて調査や検証を行い、設定変更 * 更改(オンプレサーバ・NASの構築,Windows Serverの更改,ADのFSMO移行,ファイルサーバ移行) # 行なった改善活動 * ADのユーザ新規登録・属性変更・削除をPowerShellスクリプトにて自動化し、トイルを削減 * Google Apps Scriptを用いて顧客とのメールの定型文や日報の作成などを省力化 * ファイルサーバ内の最終更新が〇年以上前のファイル情報をPowerShellを用いてCSVで出力し、一括削除した経験 * ファイルサーバ以降に伴い、それまで手作業だったファイルサーバのアクセス権の付与をPowerShellで行い省力化 * AzureのLog Analytics ワークスペースにてKQLを工夫し稼動レポート作成に必要な情報(時刻,ユーザーID,使用モデル,消費トークン数)を収集した経験 * 手作業で行っていたAWS EC2の構築作業をCloudFormation化 * 申請対応手順書一覧など、業務引き継ぎに必要な資料が不足していたため自ら作成