備忘録などいろいろ

イロイロ! 比較的Twitterの延長のノリで書くと思います。

災害への備えを見直したので書いておく

この記事について

災害への備えを見直したので、その記録です。

まえがき

2024年1月1日に、令和6年能登半島地震が発生しました。当時私は能登地方の玄関口とも言える石川県河北郡に帰省しており、父の還暦祝いの最中に震災を体験しました。断水はあったものの立地が幸いし、断水以外の具体的な被害はなく事なきを得ました。

一方で、能登地方の被害状況が明らかになるにつれて、今回の件も外出先がちょっと違っていたら/帰省先の立地がちょっとズレていたら/なにか一つ運が悪ければ住居を失ったりライフラインを断たれたりという状況に陥っていたことを痛感し、改めて災害への備えを見直すことにしました。

記事を読む際に念頭においてほしいこと

一般的に言えることですが、本記事に書かれている備品リストがすべての人にとって正解ではありません。備品リストは「自宅の立地」「周辺環境」「日常の行動パターン」「想定リスク」「本人の求めるもの」によって変わってくるので、各自がしっかりと自分にあったキット構成を考える必要があります。そういう意味では、世に出回っている「防災セット」のような出来合いのキット商品を買っておいておけば万全ということはありません(もちろん無いよりはマシですが)。

とはいえ、筆者が多少Preppers気質を持ち合わせた人物であることは確かなので、その点は折り込んで読んでいただければ幸いです。

想定

周囲環境

居住地は首都圏郊外、勤務先は東京、自宅から300m離れた場所に平置き駐車場と車あり。

考慮事項

次のことを念頭においています。

  • 非常時とっさに掴んで持ち出せるものの量は限定的なので減らす
  • 自宅から避難しないといけなくなる状況下では、自宅の備品は持ち出せないことを前提とする
    • つまり、シェルター構築のための備品は自宅ではない場所に置いておくべき
  • 家族がいるため、帰宅困難を避けることを重視する
  • 予算効率を高めるため、複数箇所に冗長配備するものは最小限にし、複数の用途で使えるものをキットに入れる

想定リスク

リスクとして下記を想定しています。

  1. 災害による怪我等一次被害で行動不能になるリスク
  2. 交通網が破壊され帰宅困難になるリスク
  3. 通信網がダウンして連絡が取れなくなるリスク
  4. 家が壊れてシェルターがなくなるリスク
  5. 水、電気、ガス等のライフラインが断絶するリスク
  6. 車道が破壊され避難困難になるリスク

対策

キット構成

キットは次のように分けています。シーンによってそれぞれ、使えるケース、使えないケースがあります。

キット 用途/配置/内容物の例 自宅が倒壊 外出時 一次避難時 二次避難時
シェルターキット 自宅が使えなくなった際にキャンプするためのもの。タープや寝袋、テント/ツェルト、ポータブル電源、食料等。平置き駐車場に停めた車に積んでおく。
宅内備蓄キット ライフラインが復旧するまで自宅で過ごすための宅内備蓄。食料、水、照明器具等。
特殊キット 追加の通信機器、ロープ、ノコギリ等。持ち出せれば儲けもの、ぐらいのイメージ。家の玄関先あたりにコンテナに入れて置いておくつもり。活躍の機会は極めて限られるので普通は用意しない。
玄関先キット 被災初動でとっさに掴んで持ち出すもの。救急キット、ヘッドランプ、メモ帳。できればスリッパも。玄関先に置いておく。
EDCキット 外出先から自宅まで帰るために必要なもの。救急キット、防寒・雨対策、携帯用電源等。基本的に徒歩圏内以上の外出時は常に持ち歩く。
最小限キット カバンを持たずに外出するときでもポケットに入れておくもの。鍵、財布、スマホ等。

各シーンにおいて、使えるキットを複数組み合わせるとその時に必要になるものがある程度集まるように分散配置してあります。

リスク対応表

想定リスクに対して、使えるキットはこのような関係になっています。

リスク内容 シェルターキット 宅内備蓄キット 特殊キット 玄関先キット EDCキット 最小限キット
災害による怪我で行動不能になるリスク - - -
交通網が破壊され帰宅困難になるリスク - - - - -
通信網がダウンして連絡が取れなくなるリスク - - - -
家が壊れてシェルターがなくなるリスク - - - -
水、電気、ガス等のライフラインが断絶するリスク - - - -
車道が破壊されて避難できなくなるリスク - - -

キット内容

キットの内容物詳細はこのとおりです。

  シェルターキット 宅内備蓄キット 特殊キット 玄関先キット EDCキット 最小限キット (備考)
バックパック           シェルターキットを背負って徒歩避難しないといけないケースのため、登山バッグを使う
タープ + ポール + 張り綱            
ツェルト           雨具、防寒、テント代わり
寝袋            
ウレタンマット            
水フィルター           川の水などから飲料水を作る
携帯トイレ            
ツーバーナー            
ポータブル電源            
折りたたみエンピ           スタックしたとき用
食料 + 飲料水         車に積むものは乾麺などに限定
LEDランタン            
毛布            
HF無線機 + 周辺機器           アマチュア無線
アンテナキット           アマチュア無線
12Vバッテリー           アマチュア無線
ヘルメット           スキー用のものを玄関に置いておく
ハーネス + カラビナ           まずないが、あれば懸垂下降できる
ロープ + スリング            
OD缶 + マイクロバーナー           お湯を沸かせる
コッヘル等            
のこぎり           フィールドクラフト用
ナイフ           調理用、フィールドクラフト用
スリッパ            
ヘッデン          
メモ帳 + ペン         防水ペン、防水メモを書き置き用に
ハンディ無線機           見通し距離の通信のため、アマチュア無線
モバブ + 充電ケーブル            
フラッシュライト            
携行食            
ポンチョ + パラコード           雨具、防寒、タープ兼用
Shemag           防寒、水の一次フィルタ、タオル兼用
スペア靴下           靴下が濡れると歩けなくなります
サバイバルキット            
└ ライター            
└ ワセリン           靴ずれ防止、軽いけがの処置用
コンタクトレンズ            
└ 浄水タブレット           飲水を作る
└ 折りたたみ水ボトル            
└ コンパス            
└ 現金           財布とは別にもって
└ 除菌シート            
└ テープ           何かと便利
IFAK          
└ QuikClot等       止血剤入りガーゼ
ニトリルグローブ          
└ Alcohol wipes         消毒用アルコールワイプ
└ Duct Tape         ガムテープを少量取って折り曲げて入れる
Bandage          
└ 鎮痛剤         バファリンなど、頭痛だけでなく痛み止めにも使える
└ Emergency Sheet         金銀のキラキラしたシートを防寒兼用に
└ 止血帯         なくてもOK
ヨウ素         なくてもOK
家の鍵            
車の鍵            
財布            
スマホ            


以上

Amazon Elastic Beanstalkのお付きのRDSはけっこうやばい

Elastic Beanstalkで環境を新規作成するときに、同時にRDSインスタンスを作ることができるんですよね。
で、安定稼働してしまうと、どうしてもappサーバとdbサーバは別々に動いていると思い込んじゃう。
ある日突然ebの環境が調子悪くなったりして「再構築」ポチッと押すと、昔々ebの環境の一部として作ったRDSインスタンスまで落とされて再構築されてしまい、現場は大パニックに。なんてことが起こることがあるかもよ?
これ、どれくらい皆さんやらかすのか分かってないんですが、やりがちっぽいし、自分もやっちまったし、やばい。なんとかしろ。
まあ、RDSはebとは別に作るのが良さそう。

HerokuでRails動かすときのカスタムLogFormatterでハマった話

結論から言うと、Rails 5を使うときはrails_12factor gemは使わないほうが良さそう。

アプリケーションログベースでの監視をしたい/アラートを上げたいので、loggerの上げるログのseverity(ログレベル)の情報はかなり重要。この辺の情報はloggerのformatterにActiveSupport::Logger::SimpleFormatterを使っちゃうと消されてしまうが、::Logger::Formatterを使えば指定すれば消されずに出力される。

config/environments/production.rb

config.log_formatter = ::Logger::Formatter.new

 しかし、herokuにデプロイしているアプリで上記のFormatterが動いてくれずに非常に時間を消費してしまった。いくらformatterを変えても、強制的にActiveSupport::Logger::SimpleFormatterが使われてしまう。そういえば、rails_12factor gemってherokuでログを標準出力に吐き出す設定を良しなにやってくれるgemだったっけ?考えられるとしたらこれしか無いな...

github.com

If you are starting a new application with Rails 5, you do not need this gem.

Rails 5ではもうこのgem要らないらしい。マジか。

Gemfileからgem "rails_12factor"の行を消したらちゃんと動いた。

 

Elastic Beanstalkへのデプロイ方法その3

先日の記事で、Elastic Beanstalkへのデプロイ方法には2通りあると言った。このたび、その2通りのちょうど中間に当たる方法が解ったのでメモ。前提として, awsebcliというpipパッケージを利用してコマンドラインベースでdeploy処理を走らせる場合のお話。

qpshinqp.hateblo.jp

上記の2パターンをまとめると下記のようになる。

パターン1: 丸ごとzipアップロード方式

メリット:

  • 簡単

  • .ebextensionsによるeb環境ホストの設定injectionが可能

デメリット:

  • デプロイ所要時間が短い

eb deployコマンドのデフォルトの挙動で, ebプロジェクトルートディレクトリ内すべてをzip化し, ebプラットフォームにアップロードする。

eb環境ホストは上記zipを落としてきて, docker buildした後docker runし, アプリケーションが動き出す。

パターン2: dockerリポジトリpull方式

メリット:

  • デプロイ所要時間が短い

デメリット:

  • .ebextensionsによるeb環境ホストの設定injectionができない

どこかのdockerリポジトリに予めdocker buildしたimageをpushしておく。

Dockerrun.aws.jsonファイルにそのimageの所在(リポジトリ:タグ)を指定しておき, Dockerrun.aws.jsonファイルのみをebプラットフォームにアップロードする。

eb環境ホストはDockerrun.aws.jsonに指定されているdocker image情報をもとにリポジトリからimageをpullし、docker runすることでアプリケーションが動き出す。

中間手法: buildartifact.zip方式

メリット:

  • デプロイ所要時間が短い
  • .ebextensionsによるeb環境ホストへの設定injectionが可能

デメリット:

  • デプロイの下準備が比較的面倒

eb deployによりzipアーカイブをアップロードし, それをもとにdocker runするのはパターン1と同じなのだが, zip生成過程を自前で準備するという点がパターン1と異なる。

zipアーカイブの中身に, 動かしたいdocker imageのリポジトリ:タグ情報を格納したDockerrun.aws.jsonと、.ebextensionsディレクトリのみを格納する。

これにより、パターン2と同様にeb環境ホスト側でのdocker build処理を回避しつつ、.ebextensionsによる設定injectionを可能にしている。

まあ、知っている人は知っているのかもしれないがいろいろと試行錯誤したのちにこの方法に落ち着いた。

AWS ElasticBeanstalk で Docker 動かすときの備忘録

単一コンテナ環境で何回かやってるんですが、dockerコンテナのデプロイ方法には2種類あります。この方法の選択についていつも忘れてしまうので備忘。

方法1: Amazon ECR などに事前に `docker build` したイメージを push しておいて、ElasticBeanstalk に Dockerrun.aws.json だけを食わせて ECR からpullしてきて起動
方法2: railsのファイルやらDockerfileやらを全部 zip にしてeb deployか何かでアップロードする

普通に考えれば、方法1は可搬性のあるdockerということだし手元で `docker build` してしまったほうがエラー対処の手戻りが少なかったり、EB上でbuildしなくていいのでEBのUpdating state時間が少なくなって楽なのだが、ある問題が生じる。

問題:
.ebextensions でdocker hostに関する設定のinjectionができない。
したがって(単一コンテナ環境では)awslogs (CloudWatch Logs) へのアプリケーションログのストリーミングを行う手段がない。
※方法1ではEBはDockerrun.aws.json というマニフェストに従って docker image のみをpullするので.ebextensionsが介入するタイミングが無いとかそういうやつ。

ということで、deployプロセスが冗長になりがちだが仕方なく方法2を使うのである。デプロイの時間はもちろん長くなるが、苦渋の選択です。

ハンコン G29 のペダルメンテナンス

ハンコン(Logitech G29)のブレーキペダルの調子が悪くなったのでメンテナンスしたら直った。

あんまりいないと思うが、万が一同じ症状で悩んでる方がいた場合のご参考として記しておきます。

症状:

ブレーキリリース直後、ブレーキに触っていないのにもかかわらず、入力値がピコピコ変動する(英: spike)

このため、レースシムなどで遊んでるとコーナーの立ち上がりがめちゃくちゃ遅かったり、不意に荷重変動してスピンしたりする

なお、ソフトウェア側でブレーキペダルの遊びを調整しても改善しない(入力値のノイズにけっこうな値のバラつきがあるため)

 

原因:

ブレーキペダルのセンサー部(可変抵抗器/ボリューム)の変位0付近における接触不良

 

対策:

1. 可変抵抗器をバラして接触面及びブラシ電極を掃除した(無水アルコールで拭いたが、もっと良いのがあるかも)

2. ブレーキペダル内の歯車の山をひとつ分ズラして、可変抵抗の変位0付近を使わないようにした。
2'. もしかするとソフトウェア側でブレーキペダルの遊び調整が必要かもしれない(自分の場合は不要でした)

参考:

www.gtplanet.net

この情報、日本語でググってもなかなか出てこなかったので情報格差を感じる。

読んでわからなかったらコメで聞いてください。