1. yammerの日記
  2. gawkとgraceful shutdown
2024-01-23 09:11

gawkとgraceful shutdown

といっても、gawkではやっていないのですが。

 

飲んだ日本酒は「尾瀬の雪解け」

00:02
こんにちは。
今日も夜の道を歩きながら、帰りに撮っています。
と言っても、今日はいつもとはちょっと違う道を歩いていて、
お酒を飲んでて、ちょっと飲みすぎて、一息乗り過ごしてしまって、
ちょっと違う道を歩いています。
そろそろいつもの道に戻るんですけどね。
ここ一年か二年かぐらいに、日本酒を飲むようになって、
そんなに辛いのは飲まないんですけど、
今日飲んだのも美味しくて、
あとですね、お酒を飲んだ後に、ちょっと酔っ払ってる中、
夜道を歩いて酔かずに当たるっていうのが結構いいですね。
気分が変わるというのもあるし、酔いが冷めるというのもあって、結構好きです。
昔というか何年か前から、30分とか1時間とかでも、
割と歩いてしまうところがあります。
そんな浮かれた話もあるんですけど、
仕事でちょっと反省するなという部分もあって、
ちょっと仕事でバタバタとしているところがあったりして、
自分がとある仕事をお願いしている別のパートナーの方に、
今ちょっと忙しくて、みたいな言い訳をしてしまったんですよね。
言い訳というのは本当に良くないですね。
それが正当なものであって、
説明するっていうのは良いんですけど、
私が言ったのは言い訳で、
その人にとっては正直あんまり関係ないというか、
そういう人はすごい色んなことを国にとってやってくださって、
持って息を見捨てるのに言い訳するっていうのは、
やっぱり良くないですよね。
それは結構反省だなっていうのがあって、
言い訳をしないっていうのが今日の反省です。
いつも奥の話をしているので、
今日も奥の話をしたいと思います。
そうですね。
何の奥の話をしようかちょっと迷っているので、
奥の実装をちょっと見ますか。
03:03
何の話をしようかな。
家も近いのでそんな複雑な話はしないんですけど、
結構色々話しましたね。
そうだな。
迷いますね。
テンプレートエンジンの話は面白いんですけど、
ちょっと短い時間では話せないような気もするな。
あれですね。
グレースフルシャットダウンの話をしましょう。
プロダクションレイディーなウェブアプリケーションでは、
よくグレースフルシャットダウンというのが求められると思います。
どういうものかというと、
HTTPのリクエストを受け取ったら、
ちゃんとレスポンスを返してから、
プロセスが終了するというのが求められると思います。
例えばデプロイのタイミングとか、
現代のアプリケーションだったら、
いろんなタイミングでプロセスが終了して、
また立ち上がるということがあると思うんですね。
そういうタイミングで、
HTTPのリクエストをちゃんと返さずに終了すると、
リバースプロキシがエラーを返したり、
リバースプロキシがもし存在しなかったら、
レスポンスをちゃんと返せなかったり、
そういうことが起こってしまいます。
そういうのが良くないと、
普通にちゃんと正当なリクエストを投げたら、
ちゃんとレスポンスを返してほしいということで、
レスポンスを返してから終了するというのが求められていると思います。
私が作っているジオークのウェブアプリケーション、
オークブログでもこれを実装しています。
実装しているといっても、
オークでやっているわけじゃなくて、
実はシェルスクリプトでやっています。
ドッカーのコンテナでアップしているので、
ドッカーでどういう風にグレースフルシャットアンが行われるかというと、
コンテナが終了するときに、
プロセスシグナルというのが飛びます。
シグタームというプロセスシグナルが飛びます。
これを適切にハンドリングできれば、
グレースフルシャットアンが実装できます。
適切にというのはどういうことかというと、
Httpリクエストを処理し終わってから、
終了するということです。
シェルスクリプトを使っていまして、
シェルスクリプトでトラップというコマンドがあります。
06:03
このトラップというコマンドで、
シグタームを受けたら、
特定のシェル関数を実行することにしています。
どういうシェル関数を実行するかというと、
カールコマンドで、
プライベートなエンドポイントで、
アプリケーションをシャットダウンするエンドポイントを叩くことにしています。
OrgブログのWebアプリケーションの方では、
シャットダウンするエンドポイントを叩かれると、
リクエストを返した後に終了するという実装になっています。
これは、シェルスクリプトと、
Webアプリケーションしか知らない秘密のトークンを使って、
スロー・オーソライゼーションヘッダで認可して、
リクエストを受け取るという風にしています。
こうすると、
プロセスに対してシグタームが飛んでくると、
シェルがそれをトラップして、
終了のリクエストを投げると、
GOrgのプロセスが、
シャットダウンのエンドポイントを叩かれるので、
リクエストを返した後に終了すると。
これだけで、グレースフルシャットダウンが実装できます。
というのも、GOrgのWebアプリケーションでは、
フォークとかイーポールとかそういうのをしていなくて、
プレイフォークとか、
マルチプロセスとかマルチプレスレットとか、
非同期で複数のhttpリクエストを同時に扱うという実装がないんですね。
基本的には同期的に1httpリクエストごとに扱うと。
そういう実装しかしてないんで、
シャットダウンのエンドポイントを処理している間は、
他のhttpリクエストがないから、すぐに終了できるというわけです。
というわけで、そのあたりはしょぼいとも言えるんですけど、
そんな感じで、GOrgではグレースフルシャットダウンを実装しています。
結構ね、シグタンもちゃんと扱うと気持ちよくて、
コンテナをドッカンコンポーズとかで、
カチューラルにコンテナをコントロールシートから落とすと、
一瞬でちゃんと自分で扱えばすぐ落ちてくれるんで、
結構開発体験がいいですよね。
そこそこの規模のアプリケーションとかと、
そこら辺が微妙な扱いだったりして、
なんかエンジンエックスが落ちないなとか、
なんか得点のプロセスが落ちないなとか、
なんか強制終了したいなみたいな気持ちになるんですけど、
Orgで自分が作ったアプリケーションっていうのは、
大して規模が大きくないんで、
何が起こっているかっていうのを全部自分で把握できるんでね、
そのあたりは結構、
車が通ったんでちょっとうるさいと思うんですけど、
09:00
小さいアプリケーションっていうのは何が起こっているか、
全部自分で把握できるんで楽ですね。
今日はこの辺にしておきたいと思います。
ではまた。
09:11

コメント

スクロール