はじめに
こんにちは。アドベントカレンダー８日目担当の田中と申します。
パーソルキャリア株式会社で doda マイクロサービスグループに所属し、マイクロサービスシステムのインフラ領域の管理をしています。
クラウドサービスは柔軟性が高い一方で、誤操作によるリスクを伴います。特に削除に関連するヒューマンエラーは、サービス全体に影響を及ぼしかねません。
本記事では、私たちの業務で感じたリスクと、その具体的な対策について紹介します。
マイクロサービス環境の概要
まずは、私たちが運用しているマイクロサービス環境について簡単にご説明します。
このシステムでは、以下の構成で運用しています。
- ゲートウェイサーバー
- 認証認可サービス
- 各種マイクロサービス
これらはすべて、Amazon EKS 上の Kubernetes Pod として動作しています。また、AWS リソースは CloudFormation を使って管理し、インフラのコード化を徹底しています。
以下に、構成を簡単に示した図を載せておきます。
重要リソース削除がもたらす運用影響
1. CloudFormationのスタック削除
こちらは、CloudFormation で管理している場合の一般的な話です。
CloudFormation は複数のリソースをまとめて管理するのに便利なツールですが、誤って削除すると影響が広範囲に及びます。特に、データベースやロードバランサー、サーバーなど、重要なリソースが含まれている場合、その影響は甚大です。
2. EKS on Fargate のプロファイル削除
こちらは、私たちの環境特有のリスクです。Fargate プロファイルを管理しているスタックが削除されると、Pod がスケジュールされなくなり、リクエストを処理できない状態に陥ります。このような状況はサービス停止を引き起こします。
ヒューマンエラー防止対策
これらのリスクに対して、以下の 3 つの対策を検討し、現時点で実施しているものと、今後実施する予定のものについて紹介します。
1. 作業ルールの明確化
本番環境で作業する際には、クロスチェックを義務付けるルールを導入しています。
また、リリース計画には以下の項目を明記し、他メンバーにレビューをしてもらっています。
- 作業手順
- リリース後の動作確認方法
- 異常が発生していないかの確認方法
- 異常発生時の切り戻し方法
- 障害発生時の影響範囲
これらの項目を手順のレビューで確認することにより、ヒューマンエラーを防ぎ、万が一異常が発生した場合には、早期検知と障害影響の最小化を図る対策を講じています。
2. 適切な権限管理
作業者は一時的に必要最低限の IAM ロールに切り替えて作業するようにしています。現在、以下のようなロール区分を想定しています。
- Admin 権限
- インフラ構築用の権限
- アプリケーション開発者用の権限
- リリース担当者用の権限
- ReadOnly 権限
- 機密情報(シークレットなど)以外の ReadOnly 権限
作業時に最低限必要な権限のみを付与することで、誤操作による余計なリスクを技術的に制限できる仕組みを構築する予定です。
また、単にロールを整理するだけではなく、各作業に適したロールを明確化し、それに基づいたルールを徹底することでヒューマンエラーの発生リスクをさらに低減できる体制を目指しています。
3. 削除保護の設定
AWS の機能で削除保護を活用することで、リソースの削除リスクを低減する予定です。
-
CloudFormation のスタックの削除保護設定
- AWS リソースの削除保護設定
さらに、静的解析ツール（lint）を導入し、削除保護が適切に記述されているかを自動でチェックする仕組みを検討しています。
まとめ
ヒューマンエラーは、単なるルール化や技術的な仕組みだけでは解決できません。仕組みと運用を組み合わせることで、ヒューマンエラーを最小限に抑えることが可能だと考えています。
ミスによる不幸をなくし、より安心して運用できるシステムを目指していきましょう。
田中 貴弘 Takahiro Tanaka
プロダクト開発統括部 dodaシステムアーキテクト部 dodaマイクロサービス部 エンジニア
2023年4月にパーソルキャリアへ中途入社。dodaサイト開発チームを経て、2023年10月にdodaサイトのマイクロサービスPJTに参画。
※2024年12月現在の情報です。
