ID:66993さん

# 概要 - プロジェクト内容: 現在稼働中自社サービスの運用保守 - プロジェクト規模: Dev チーム 6 人 SRE チーム 4 人の合計 10 人 - 担当: SRE チームのメンバー 既存の問題点解消を担当 ## 担当 - システム構成の問題点解消 - ローカル・開発・ステージング環境の整備 - ドキュメント化・整理 - デプロイ作業改善 - テストやバックアップ等の手動で実施していた部分の自動化 - 他グループへの情報提供ツール整備 - 開発支援・開発ルールの提案 - 既存の問題を解消するための調査と検証 ## 使用技術 - インフラ - AWS(EC2、LB、S3、RDS、AWS CLI、Lambda、EFS、EventBridge、Parameter Store、Route53、Patch Manager) - 言語 - PHP、Python、Javascript、TypeScript、HTML、CSS、shell script、Google Apps Script - フレームワーク - FuelPHP - データベース - MySQL8(Aurora MySQL) - バージョン管理ツール - Bitbucket、GitHub、GitHub Actions - コミュニケーションツール - slack、Zoom、Google Meet - その他 - Docker、Docker Compose、Apache、Metabase、PlayWright、Notion、Google Drive、Google Sheets、CDK ## 課題 - システムに単一障害点が存在している。 - ステージング環境とプロダクト環境で構成が異なっている。 - 開発環境が整備されておらず、開発時のボトルネックになっている。 - デプロイ作業が手動で行われている。 - 情報やファイルの共有が個人間で行われており、必要なものが共有されていない。 - テスト内容や確認方法が実施者に依存している。 - 他グループとの情報共有時に直接 SQL を実行している。 - 既存定期実行処理を見直す必要がある。 - セキュリティパッチの適用が行えていない。 - CICD 環境の構築。 - IaC による環境構築の自動化とそのための課題の解消。 ## 取り組み ### システムの単一障害点を解消 - 単一障害点解消のためにシステム構成の見直しを行った。 - ロードバランサー(NLB)の配下にメールサーバーを設置して冗長性を確保しました。 - NFS を EFS へ置き換えることでストレージの効率性と拡張性を向上させた。 ### ステージング環境とプロダクト環境の構成が異なっているのを解消 - ステージング環境と本番環境間での構成の差異が、リリース前のテストの障壁となっていたので、問題を解消するための対応を行った。 - ドキュメントの作成: 環境構築の手順が明文化されていなかったため、まずは現行の構成や設定を調査してドキュメント化しました。 - 環境の再構築: 上記のドキュメントを基に、ステージング環境を再構築し、本番環境との構成の統一を図りました。 ### 開発環境が整備されておらず、開発時のボトルネックになっている問題の解消 - ローカル環境の構築ができず、開発のボトルネックになっていたので、問題を解消するための対応を行った。 - 必要なファイルがリポジトリにコミットされていなかったため、pull しても正常に動作しない状態だったものを問題なく動作するようにファイルを整理した。 - Docker と shell を活用して、ローカル開発環境のセットアップを自動化し、環境構築の手間を削減しました。これにより新しい開発者も迅速にプロジェクトに参加できるようになりました。 - ツールを導入し、データベースのスキーマをバージョン管理することができるようにしました。これにより、変更履歴を追跡しやすくなり、複数人の開発者が作業してもスキーマの整合性を保ちやすくなりました。 - ローカルのデータベースのデータをバージョン管理する体制を整えました。さらに、データの反映を自動化することで、データの変更があった際にも迅速に更新内容を反映できるように改善しました。 - ローカル環境のセットアップに関する README と FAQ を新たに作成しました。これらのドキュメントの導入により、新規メンバーが遭遇するであろう問題を予防し、環境構築の手順を迅速に進められるようサポート体制を整えました。 - ローカル環境で発生したエラーの一覧をNotionで共有することにより、同様のエラーが再発した際、すぐに解決策を提供できる体制を整えました。 - 開発環境を Visual Studio Code に統一し、チーム内での設定やプラグインの差異を解消して一貫性のある開発環境を実現しました。 - extensions.json、settings.json、launch.jsonを共有し、チームメンバー全員が同じ開発環境で開発を行えるようにした。 - extensions.jsonにより開発支援のための拡張機能をスムーズに導入できるようにしました。 - settings.jsonによりインデントや改行コード、使用するフォーマッター等を統一することで一貫したコーディングスタイルを提供できるようにしました。 - launch.jsonによりxdebugを環境構築時から使用できるようにし、デバッグプロセスを効率化しました。 - 一部の設定値がコード内にハードコーディングされていたため、環境構築時にそれらの値を手動で書き換えを行っていたのを解消。 - 設定値を一元管理する設定クラスを作成し、環境構築時の手動の作業が減少し、エラーのリスクを低減。 - 管理されていなかった古いパッケージ、設定ファイル、その他のリソースなどをバージョン管理できるようにしました。 - 環境構築の自動化を進めるためにこれらをGitリポジトリに追加してバージョン管理できるようにして新規環境の構築やIaC対応を容易に進められるようにしました。 - テスト時のメール誤送信を防止するため、ローカル環境でメールの送受信をテストできるようにしました。 - Dockerを使用して、dovecot(IMAPサーバー)、postfix(SMTPサーバー)、およびroundcube(Webメールクライアント)を組み合わせたコンテナを作成して、Webブラウザ上からメールの送受信を確認できるようにしました。 ### デプロイ作業が手動で行われているのを解消 - デプロイ支援スクリプト作成し、手動で行っていた作業の自動化を行った。 - デプロイ作業の効率化と安全性向上のため、デプロイ支援スクリプトを作成しました。また、このスクリプトの使用方法を示す作業手順書も同時に提供し、手動で行われていたデプロイ作業の簡略化とリリースのミスを低減できるようにしました。 - 以下作成したスクリプト - 現在使用中のソースコードをバックアップするスクリプトを作成し、問題が発生した場合に迅速に元の状態へ戻せるようにした。 - リリース予定のファイルと既存のファイル間の差分を確認するためのスクリプトを作成し、リリース前の確認作業が容易になり、意図しない変更や漏れがある場合に迅速に察知できるようにした。 - データベースの更新作業の効率化を図るため、SQL の実行を自動化するスクリプトを作成し、リリースディレクトリに更新用の SQL を配置し、リリース時に自動的にそれらが実行されるように変更しました。 - リース実行用のスクリプトを作成し、更新用ファイルの反映を自動化を行い、リリース時の更新漏れを防止できるようにしました。 ### 情報やファイルの共有が個人間で行われ、必要な情報が共有されていない問題の解消 - Notion と Google Drive を使用して情報とファイルの一元管理と共有を実施。 - 散らばっていた情報や必要なファイルを一元化するため、情報は Notion へ、ファイルや資料は Google Drive へ集約するように周知しました。 ### テスト内容や確認方法が実施者に依存する問題を解消 - API の自動テスト環境を構築しました。これにより、実施者に依存せず一貫したテストが実施できるようになりました。 - テスト仕様書に基づき、Google Sheets でテストデータを作成できるようにしました。更に、Google Apps Script を使用して、このシートから直接テストデータファイルを生成できるように実装しました。 - 作成したテストデータファイルを自動で読み込んでテストを実行するプログラムを開発しました。テスト結果は Google スプレッドシートに出力され、結果の確認が直感的に行えるようになりました。 - テストデータの作成からテスト結果の確認までの一連の流れについての手順書を作成し、テストの実施をより簡単にするためのガイダンスを提供しました。 - OpenAPI (Swagger)を活用して、テスト仕様書の基礎となる部分を自動生成できるようにしました。 - ソースコード内のアノテーションを用いる方法をチーム内で共有し、これをもとに API ドキュメントを作成するための基本情報を取りまとめました。 - 実際のリクエストデータからアノテーションを自動生成するスクリプトを開発し、開発者がソースコードにアノテーションを簡単に追加できるようサポートを実施しました。 - アノテーションから直接 yaml ファイルを生成し、API ドキュメントを簡単に作成できるようにしました。 - API ドキュメントの閲覧用として Swagger UI や Redoc を導入。これによりテスト仕様書の作成サポートを強化しました。 ### 他グループとの情報共有時に直接 SQL を実行していた問題の解消 - BI ツールとして Metabase を導入し、ビジネスサイドやカスタマーサクセスサイドに情報を効率的に提供できるようにした。 - お問い合わせ対応チームにも Metabase を開放し、データベースからの情報取得を容易にし、顧客の問題解決が迅速になるようサポートした。 ### 既存定期実行処理の見直し - RDS のバックアップ処理が cron で実行されていましたが、管理のしやすさや柔軟性の向上を目的として、AWS Lambda での実行に置き換えました。 - RDS のログを定期的に S3 にバックアップするスクリプトを作成し、長期的なログの保管と分析を可能にしました。 ### セキュリティパッチの適用が行えていない問題の解消 - ステージング環境とプロダクト環境の構成が異なっていたため、一貫したセキュリティパッチのテストと適用が困難だったが、構成の違いを解消することで、ステージング環境でのパッチ適用とその動作確認が行えるようになりました。 - セキュリティパッチの適用を自動で行えるように仕組みを整備した。 - 新しいセキュリティパッチの有無や適用状況を定期的にスキャンし、その結果を Slack で通知するようにした。これにより、必要なパッチが適用されているかを確認できるようになった。 - パッチ適用後の動作確認手順書を作成し、問題が発生した際の対応手順を明記した。 ### CICD 環境の構築 - 現在環境構築中 - Bitbucket から移行。GitHub への移行理由として、GitHub のコミュニティにおける豊富な知見やリソースを活用する目的。 - GitHub Actions の導入。プルリクエスト作成時には、Reviewdog（コードレビュー支援ツール）を利用してコードの品質確認を行い、問題点を指摘。また、merge 時には自動デプロイを行う設定を導入して効率化を図った。 ### IaC による環境構築の自動化とそのための課題の解消 - バージョン管理下にないリソースを整理し、再現性と一貫性を持った環境構築を目指し対応中。 - 以下取り組み内容 - Git を使用して、サーバーやミドルウェアの設定ファイルや必要なパッケージをバージョン管理に含めた。 - 環境ごとの差異を吸収できるように、設定ファイルに環境変数を埋め込むことで、複数の環境に対応できる構成を取り入れた。 - コミットされたリソースを展開するためのスクリプトを作成し、環境構築を自動で行えるようにした。 - 初期状態の EC2 インスタンスを各種サーバーへセットアップするためのスクリプトを作成し、サーバーの初期設定を自動化した。(必要なパッケージのインストール、リソースの展開、ユーザー作成、sshd 等のサーバー設定) - AWS CDK を使用してインフラをコードで管理し、自動構築の対応を進行中。 - 以下取り組み内容 - 構築した環境から AWS CDK で使用するための AMI 作成自動化対応中。 - ネットワーク構成をコードで管理し、構築を自動化。 - S3、EFS のリソースの構築を自動化。 - EC2 インスタンス、ELB の設定、デプロイを自動化。