App Engineの自動再起動には超えるべきステップが二つある
- Google App Engine は Compute Engine のように素朴な VM ではないので OS 内部から再起動することはできない
- App Engine の instance は service, version で特定しないといけない
- App Engineには機能がないのでスケジュールは外部から与える必要がある
※ VM インスタンスの起動と停止をスケジュールする | Compute Engine ドキュメント | Google Cloud Compute Engine にはインスタンススケジュールがある
instanceの特定
App Engine の概要 | App Engine ドキュメント | Google Cloud
App Engine は以下のように
- service
- version ...
App Engineの定期実行で困っていたこと
Google App Engine でバッチジョブを動かしていて、ある時「何のエラーも出ていないが処理が止まってしまう」状態に遭遇した。いわゆるフリーズ / ストールしている状態。
そういや昔は Windows の OS そのものが連続何日間稼働で無反応になるだの、Webサーバが無反応になるだの色々あったけど、最近はこういうことに気を使う必要があるケースはほとんどなかったなーなどと思いながら、はてどうしたもんかと考えていた。
- このプロセスは24h稼働させっぱなしではなく、必要なタイミングに自動で起動して自動で終了する予定なので、常時外形監視のような形でエラーを拾うのもなかなか面倒な仕組みになってしまう1
- プロセスは何のログも吐かなくなってしまうので、プログラムコード自体を修正せずに中の情報を引き出すのは難しい
- 正常に動作しているログは逐一出力しているが、「特定のタイミングで一定時間以上正常なログが途切れている」みたいな条件での監視をアリもののサービスだけで実現するのはなかなか難しそう
ということで、プロセスそのものに注目してエラーが起きていることを知るのはちょっと難しそうだった。
<h2 id="そもそもcronジョブはプロセスのストー...
何を今さらシリーズ。
データの安全性、共有可能性には段階がある
「一部」のグレードがもっと細かくなるかどうかの違いはあるにせよ、基本は以下のような3段階になるはず。
- 一部の人のみ利用可能なデータ
- 一定までの配慮で共有可能なデータ
- 完全に公開、共有可能なデータ
データ共有が始まると共有物は無限に増える
多くの場合、組織は 1 ではなく 2 のグレーな状態のデータを扱っている。具体的にはさすがに社内限定くらいはなんとなく思っているが、特定の業務に携わっている人のみ限定して閲覧可能、みたいなもデータも当然増えてくる。（例えば個人情報、プライバシー情報など）
<figure c...自分が何らかのソフトウェアシステムを考える際に意識していることを平易に、直感的に書き起こしておく試み。
何を当たり前のことを、と思われたなら成功。
やりたいこととシステムの立ち位置
本来システムはユーザーと目的によって最適解が異なる
目的の達成をシステムは支援する。
たまたま同じデータを利用すると同じシステムを解としたくなる
<figure class="j...課題
command | original-filter上記のような pipe をまたいだ shell script を CI で利用していたが、前段のコマンドの失敗を exit status として伝えることができておらず、CI は常に succeed 扱いになっていた。
command は fail しているのに original-filter は succeed なので常に succeed 扱い。
解決
【POSIX準拠】set -o pipefailを使おう！ただしdash、テメーはダメだ #ShellScript - Qiita
がすべてなのだが、
- 昨今、便利なクラウドは Ubuntu ベースが多く、今回の CI も Ubuntu なため、
/bin/shを shebang に指定したスクリプトは（恐らく）dash で動いており、上の指定は意図通り動作しない - ということで改修箇所は以下の通り。
# /bin/bash set -o pipefail感想
dash なぁ…。bash や zsh を標準に...
今回やりたかったのは Cloud IAP という Google がいい具合に処理してくれる認証用の proxy サーバを Cloud Run の前段に置き、特定の人しかアクセスできないようにすること。
Cloud Run には直接 IAP を設定することができず、必要な準備がいくつかある。今回はこの実現のために必要な準備を確認した。
Cloud IAP, Cloud Load Balancingをおさらい
Cloud Run は Cloud Functions 同様、そもそも認証情報付きでしかアクセスできないようにすることもできるが、Cloud IAP ( Indentity-Aware Proxy ) はアカウント単位で許可する人を登録したり、Google Workspace と組み合わせてドメイン丸ごとに対して設定することで、社内限定公開のようなものをお手軽に実現できるスグレモノだ。ただし Cloud IAP を直接設定できるのは App Engine ( GAE ) だけで、それ以外は Cloud Load Balancing のアプリケーションロードバランサと組み合わせる必要がある。
Cloud Load Balancing には L7 アプリケーションロードバランサ（外部/内部）、L4 ネットワークロードバランサ（外部/内部、プロキシ/パススルー）があるが、今回利用するのは外部アプリケーションロードバランサになる。VPN を使わず、インターネ...
背景
ActiveJob の backend は意外と悩ましい。
ActiveJob は本来 Rails 専用でも ActiveRecord 専用でもないはずだが、いざ adapter を選んでみると Rails + PostgreSQL 前提です、みたいなことが意外にあったりする。また人気のバックエンドだった Redis も近年はクラウドベンダー側と折り合いが悪かったり、意外と扱いやすくない。1 特に Rails 5, 6 が Webpacker をはじめゴテゴテしつつも変化の早い時期で、別にこれくらいなら Rails じゃなくても Hanami でも Sinatra でもいいんじゃないの？と思っていた頃は特に悩ましかった。
2024-02 現在、Rails 7 は十分シンプルになり、素の cold start の遅さがいわゆるサーバレスとイマイチ相性が悪いが、それ以外は概ね Rails でよいかもと思う状況に戻りつつある。
ActiveJobバックエンド選択時の課題
上記のような背景を踏まえ、現時点で自分が感じている ActiveJob 選択時の課題は以下のように整理できる。
- Redis 以外の安定したバックエンドが使えないか
- Resid のホスティングは以前ほどお手軽価格ではなくなっている。特にメガクラウド...
Cloud Storage FUSE | Google Cloud
Cloud Storage FUSEとは
FUSE が何か分かっている人は Cloud Storage FUSE という名前だけでピンと来ると思うが、よく分からない人のために乱暴に言うと
アプリケーションから見えるファイルシステムの中に Cloud Storage を mount できるもの
になる。図にするとこんな感じ。
※ もちろん本物のファイルシステムとまったく同じにはならないが。
Cloud Storage FUSE | Google Cloud
これまでのオブジェクトストレージを読み書きするコードの課題
Cloud Storage に限らずオ...
</div>
- Resid のホスティングは以前ほどお手軽価格ではなくなっている。特にメガクラウド...
- version ...