ID:82626さん

## プロジェクト概要 自社プロダクトで利用している7クラスターのAurora PostgreSQLを、バージョン13から16へメジャーバージョンアップしたプロジェクト。Aurora PostgreSQL 13の標準サポート終了に対応するため、約2時間のメンテナンス時間内でインプレースアップグレードを実施した。 ## 担当役割 計画策定、検証、作業手順書の作成、作業の自動化、切り戻し手順の整備、本番作業までを個人で一貫して主導。 ## 使用技術・環境 Amazon Aurora PostgreSQL／AWS CLI／Shell Script ## 背景・課題 - Aurora PostgreSQL 13の標準サポート終了に伴い、バージョン16への移行が必要だった。 - 対象が7クラスターあり、約2時間のメンテナンス時間内にすべての作業を完了させる必要があった。 - サービスのメンテナンスイン・アウト、監視の停止・再開、データベースのアップグレードなど複数の工程があり、手作業による操作ミスや作業遅延が懸念された。 - インプレースアップグレードで予期しない問題が発生した場合に備え、安全に元の状態へ戻せる切り戻し手順が必要だった。 ## 取り組み内容 ### 1. 検証環境での事前テスト 本番作業に先立ち、検証環境でAurora PostgreSQL 13から16へのインプレースアップグレードを実施した。アップグレード手順と所要時間を確認し、検証結果を基に本番作業の計画と手順を策定した。 ### 2. 作業計画と手順書の整備 事前準備、サービスのメンテナンスイン、監視停止、データベースのアップグレード、作業後確認、監視再開、メンテナンスアウトまでの工程を整理し、作業手順書を作成した。約2時間で全7クラスターの作業を完了できるよう、各工程の作業内容と実施順序を明確化した。 ### 3. AWS CLIによる定型作業の自動化 作業時間の短縮と操作ミスの抑制を目的として、AWS APIを利用する定型作業をAWS CLIによるシェルスクリプトとして実装した。また、サービスのメンテナンスイン・アウトおよび監視の停止・再開を確実に実施できる仕組みを準備した。 ### 4. 切り戻し手順の整備 アップグレード中に予期しない問題が発生した場合に備え、切り戻し手順を事前に整備した。正常系の手順だけでなく、異常発生時の対応も作業計画へ組み込むことで、本番作業のリスクを抑えた。 ## 成果 - 予定していた約2時間のメンテナンス時間内に、全7クラスターをAurora PostgreSQL 13から16へアップグレードした。 - 作業後の障害や想定外のサービス影響を発生させることなく、本番作業を完了した。 - AWS CLIを利用した定型作業の自動化により、作業時間を短縮するとともに、手作業による操作ミスのリスクを低減した。 - 検証、通常手順、監視制御、切り戻しまでを含む再利用可能な作業手順を整備した。

## プロジェクト概要 IPアドレスによるアクセス制限を設けている検証環境に対して、GitHub ActionsからE2Eテストを自動実行するため、AWS CodeBuildを利用したセルフホステッドランナーを構築したプロジェクト。GitHub標準のホステッドランナーでは送信元IPアドレスを固定できないため、CodeBuildをVPC内で実行し、固定IPアドレスから検証環境へアクセスできる構成を実現した。 ## 担当役割 技術選定、ネットワークおよびランナー構成の設計、Terraformによる構築、GitHub Actionsとの連携、導入までを個人で一貫して主導。 ## 使用技術・環境 GitHub Actions／AWS CodeBuild／AWS CodeConnections／Amazon VPC／NAT Gateway／Elastic IP／Terraform ## 背景・課題 - IPアドレスによるアクセス制限を設けている検証環境に対し、GitHub ActionsからE2Eテストを実行する必要があった。 - GitHub標準のホステッドランナーでは送信元IPアドレスを固定できず、検証環境の許可リストへ登録することが困難だった。 - IP制限を緩和するとセキュリティレベルの低下につながるため、既存のアクセス制御を維持したままテストを自動化できる構成が必要だった。 - 導入前はE2Eテストを手動で実行しており、実行作業の効率化と再現性の向上が課題となっていた。 - 常設型のセルフホステッドランナーでは、サーバのパッチ適用やキャパシティ管理などの運用負荷が発生する懸念があった。 ## 取り組み内容 ### 1. CodeBuildを利用した実行方式の採用 GitHub Actionsのジョブ実行環境としてAWS CodeBuildを利用する方式を採用した。GitHub Actionsからジョブがキューイングされた際にCodeBuild上へ一時的なセルフホステッドランナーを起動し、ジョブ終了後に実行環境が破棄される構成とした。 ### 2. AWS CodeConnectionsを利用したGitHub連携 AWS CodeConnectionsを利用して、GitHubリポジトリとAWS CodeBuildを接続した。GitHub Actionsのワークフローファイルでは、CodeBuildプロジェクトに対応した`runs-on`ラベルを指定し、E2EテストのジョブをCodeBuildのセルフホステッドランナー上で実行できるようにした。 ### 3. NAT Gatewayによる送信元IPアドレスの固定 CodeBuildをVPC内のプライベートサブネットで実行し、Elastic IPを割り当てたNAT Gatewayを経由して外部へ通信する構成とした。NAT GatewayのElastic IPを検証環境の許可リストへ登録することで、既存のIP制限を維持したまま、GitHub ActionsからE2Eテストを実行できるようにした。 ### 4. Terraformによる構成管理 CodeBuildなどの関連AWSリソースをTerraformでコード化し、既存のIaC管理体制へ統合した。これにより、構成の再現性と変更時の保守性を確保した。 ### 5. E2Eテストの自動化 手動で実行していたE2EテストをGitHub Actionsのワークフローへ組み込み、CodeBuildのセルフホステッドランナー上で自動実行できるようにした。 ## 成果 - 検証環境のIPアドレス制限を緩和することなく、GitHub ActionsからE2Eテストを自動実行できるようにした。 - 手動で行っていたE2Eテストをワークフローへ統合し、テスト実行作業の効率化と再現性の向上を実現した。 - 常設サーバを管理することなく、ジョブ実行時のみセルフホステッドランナーが起動する構成とし、パッチ適用やキャパシティ管理などの運用負荷を抑えた。 - 関連するAWSリソースをTerraformで管理し、再現性・保守性の高いテスト実行基盤を整備した。