はじめに

Cloud Run の運用中に Cloud Run が原因で提供サービスにアクセスできない事象が発生したことがあります。その際の状況、対応、対策について、過去の印象に残っている事象2件をベースに内容を記載してみます。

対象の環境の構成

LoadBalancer → Cloud Run → Cloud SQL、MemoryStore
※後続のCloud SQL、MemoryStore は結果的に事象とは無関係

障害ケース

ケース1 サービスとしてWebアクセスに応答しない

事象

対象サービスで運用しているWebサービスへのログイン処理時に5xxエラーがでている状況

内容

  • 5xxエラーがでているが、コンテナは正常に起動しており、起動停止をクエリ返している様子もない
  • 周辺の Cloud SQL の負荷状況、MemoryStore の負荷状況も平常時と同様である
  • コンテナのレイテンシーは遅くなっている状況
  • 負荷がかかりコンテナ数が著しく増減した形跡もない
  • Cloud Run のリソース状況も平常時と同様である

当該時間付近で作業があったか

Cloud Run に対して、事象発生前後にデプロイしたような形跡もなく、突然発生した。

対応

Cloud Run のサービスに対して同一リビジョンを再デプロイした。再デプロイしたところ、ログイン処理に応答し事象が解決した。

事象を振り返って

事象を振り返り気付けた点、対策として足りていなかった点を纏めます。

  • Cloud Run は異常時にコンテナ停止、起動が発生するものと思い込みがあり、調査したものの、レイテンシの遅れが異常要因と気付けなかった
    • レイテンシの遅れはあるもののリソースの負荷も少なく応答していたからと考えている(キャッシュで応答していた可能性あり)
  • 記憶ではヘルスチェック機能がGAされる前の事象だったため、定期的なコンテナ(サービスではなくコンテナ)に対するチェック機能はなかった
  • ログイン処理に異常があることから Cloud Run 以外の DB、キャッシュ、NW などその他を中心に疑っていた
  • 対策としてコンテナのレイテンシ監視、GA後にヘルスチェックを導入し低遅延のしきい値とした

ケース2 アクセス時に不定期にphpのページがテキスト形式で応答する

事象

対象サービスで運用しているWebサービスへのアクセス時に意図したレスポンスが返ってこない

内容

  • アクセス時にphpのページがテキストページで応答しphpが機能していないタイミングがある
  • 周辺の Cloud SQL の負荷状況、MemoryStore の負荷状況も平常時と同様である
  • 負荷がかかりコンテナ数が著しく増減した形跡もない
  • Cloud Run のリソース状況も平常時と同様である
  • コンテナのレイテンシーは正常

当該時間付近で作業があったか

Cloud Run に対して、事象発生前後にデプロイしたような形跡もなく、突然発生した。

対応

Cloud Run のサービスに対して同一リビジョンを再デプロイした。再デプロイしたところ、ログイン処理に応答し事象が解決した。

事象を振り返って

事象を振り返り気付けた点、対策として足りていなかった点を纏めます。

  • phpのページがテキストで応答してしまうという事象からアクセスログの応答状況の確認や、トレース状況を中心に調査していた
    • 結果的にログにSegmentation fault (11)がでていたものの気付けなかった
    • 上記ログがphpのページがテキストで応答したと思われるタイミングで複数回発生していた
  • ヘルスチェックは導入してたものの、HTTPアクセスとしては、テキストでも200応答していたことから、エラーとみなされなかった
  • 不定期に発生していたことから外形監視として、URL監視を実施していたが、検知できなかった
  • 結果的に当該事象は Google Cloud 側の基盤の障害が影響しており、それによりメモリ不足になったことにより、Segmentation fault (11) が発生していたとわかり、早めに再デプロイが必要な状況であった
  • 対策としてSegmentation fault を検知することとした

全体のおさらい

これらから得られた今後の運用にあたって必要と考えられる箇所は以下の点です。

  • 監視
    • Cloud Run のレイテンシ監視を実施する
    • Cloud Run から Cloud SQL 、MemoryStore など周辺サービスへのアクセスが正常と判断できる API の作成及び監視
  • 機能面
    • Cloud Run のヘルスチェックを実施する
  • ワークアラウンド
    • 復旧優先の場合、一次対応として当該リビジョンの再デプロイをすぐに行える体制を整える

今後期待したい機能面

Cloud Run のヘルスチェック機能はサービスとしての確認ではなく、コンテナとして確認可能な唯一方法ですが、対象のパスに対するHTTPアクセスしか行えず、またその応答内容が200であることに限られてしまっているため、ここが柔軟に調整できると、対策の幅が広がると感じました(応答文字列の確認など)。
結果的にケース2は Google Cloud 側の障害であり、ログ監視で同じ事象は検知できるものの、ヘルスチェックで検知できる柔軟性があれば、再デプロイも自動で行えることで、復旧まで行えるため、より可用性が高まるサービスだと感じました。
これからも活用したいサービスのため、ますますサービスが充実することに期待したいと思います。