ハッピールートを終わらせて 感想

諸注意

ネタバレなしで書くようにしているが、何が見た人のネタバレになるのか正確に判断できない部分もあるので
情報を得ずにプレイしたい人は見ないことを推奨


感想

俺達は、破るための約束をした。
ハッピールートで終わらせて終わらせた。
KEMCOが公式でアナウンスしている通りメタ要素を盛り込んだメタメタしたゲームだった。

ここで言うメタとはメタフィクションのことで、自分はメタフィクションはかなり扱いが難しい劇薬だと思ってる。
下手に扱えば作品そのものを破壊しかねない。しかし、うまく扱えば多次元的な素晴らしい作品になり得る。

でも、本作ではメタフィクションをあたかも普通の食材かのように料理している。
メタフィクションが劇薬だなんてこちらの認識の誤りだと言うかのように。

ウォーターフェニックスさんはこの辺りの扱いが非常にうまい印象がある。

最悪なる災厄人間に捧ぐをプレイした時衝撃を受けた。
ノベルゲームの登場人物って複数人いて当たり前みたいな考えだったから。
今回もそう。ノベルゲームに無くてはならない要素(○○○)を平気で削って平気で進行してるの
その発想がこちらにはないから善悪の判断ができない。

そんな言わばノベルゲームとしては狂った土壌の上にメタフィクションをありふれたものかのように載せてきてる。
"プレイヤー"を混乱させている。

さて、肝心のメタフィクションの部分については若干人を選ぶ感じはする。
これはこれまでゲームをプレイしてきた自分の印象から大きく変わらなかったしプレイ当初は少し体内に吸収しきれてない感覚があった。
ただ、人間って恐ろしいもので慣れてくるんですメタフィクションの応酬に。
だから、メタフィクションに適応した自分が一番恐れていたのはメタフィクションにメタフィクションを重ねてきてもう1段上に行かれる事だった。
しかし、結果としてそれはなかった。ただ、自分が予想できないようなメタフィクションの使い方をされて綺麗に風呂敷を畳まれた。悔しい。

作品中でも触れられる視点の話だった。立場によって見えるものが違うよね。と

次に、メッセージ性について
残念な事ですが、このゲームをプレイする人に非ゲーマーはいないと思う。
複雑な操作を要求しないので非ゲーマーにこそノベルゲームはプレイしてもらいたいと思うので残念ではある。

ただ、非ノベルゲーマーが初めてプレイするノベルゲームに選ぶ可能性は大いにあると思う。そう思いたい。
ゲーマーへのメッセージ性は非常に強いものがあると感じる。ただ自分自身の心情と大きな違いがなかったので自分へのインパクトはそれほどでもなかったが。

ヒロインとしてはやはりクルルが印象的。
なんでクルルが笑顔でいられるのか。浅いようで深かった。
ルートの長さ自体はクルルは長い方ではなかったと思うしその後の扱いも主役級の扱いではないと思うが
いやだからこそ印象深いのかもしれない。かなりよかった。

総じてプレイしてよかったと思える作品だった。感謝したい。

ECSタスクを安全に終了させるためにSIGTERMをハンドリングする周りの情報

SIGTERMハンドリング

タスクが停止すると、各コンテナのエントリプロセス (通常は PID 1) に SIGTERM シグナルを送信します。タイムアウトが経過すると、今度は SIGKILL シグナルをプロセスに送信します。デフォルトでは、SIGTERM シグナルの送信後 30 秒のタイムアウトで SIGKILL シグナルを送信します。この値は、ECS タスクのパラメータの stopTimeout を更新することによってタスクのコンテナ単位で調整するか、ECS エージェントの環境変数 ECS_CONTAINER_STOP_TIMEOUT を設定して EC2 コンテナインスタンス単位で調整できます。この最初の SIGTERM シグナルを適切に処理して、正常にコンテナのプロセスを終了させる必要があります。SIGTERM シグナルを処理することを意識しておらずタイムアウトまでに終了しなかったプロセスは、SIGKILL シグナルが送信され、コンテナが強制的に停止されます。

ECS のアプリケーションを正常にシャットダウンする方法 | Amazon Web Services ブログ

基本的には、上記の通りSIGTERMをハンドリングすればいいので、その内容に応じてECSタスクのstopTimeout(MAX120秒)を決めればよい。

ECSがALB/NLB配下にある場合のSIGTERM送信遅延

ECSはタスク停止時にターゲットグループのヘルスチェックでタスクをdraining状態にするが、この時点からSIGTERMがコンテナに送られるまでにデフォルトで300秒(5分)の遅延がある。

これは変更可能でターゲットグループのderegistration_delay.timeout_secondsの値を変更すれば変更できる

まとめ

  1. タスク停止
  2. ターゲットグループ:deregistration_delay.timeout_seconds(デフォルト300秒)
  3. drain完了後SIGTERM送信
  4. ECSタスク定義:stopTimeout(デフォルト30秒)
  5. SIGKILL送信

デフォルトの状態だとタスク停止実行してから実際に停止までは合計5分半くらい猶予がある

Amazon Aurora MySQL 3でBlue/Greenデプロイした時GreenはRead Onlyじゃない

掲題の通りだが、Amazon Aurora MySQL 3においてはデフォルトでGreen環境へ書き込みが許可されているようだ。


上記RDSのドキュメントには下記の記載がある。

ブルー/グリーンデプロイを作成すると、グリーン環境の DB インスタンスはデフォルトで読み取り専用になります。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html

テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作を有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。RDS for MySQL の書き込み操作を有効にするには、read_only パラメータを 0 に設定し、DB インスタンスを再起動します。RDS for PostgreSQL の場合、セッションレベルで default_transaction_read_only パラメータを off に設定します。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html

対してAuroraは専用のドキュメントが用意されておりそちらには下記記載がある。

重要

Aurora MySQL バージョン 3 では、ブルー/グリーンデプロイを作成すると、グリーン環境の DB クラスターはデフォルトで書き込み操作を許可します。read_only パラメータ を 1 に設定し、クラスターを再起動して、DB クラスターを読み取り専用にすることをお勧めします。

RDSのドキュメントを確認してRead Onlyになっている認識でいたので、Green環境を見て驚いた。
Aurora MySQL 2が2024年10月31日に標準サポート期限を迎えるため、Aurora MySQL 3にバージョンアップする機会も増えるだろうし留意しておきたい。