sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

大腸内視鏡検査を受けてきました

ナスです。今回は技術とは離れて健康について書き残しておきます。

昨年、健康診断を受けたんですが、初めて便潜血検査で要検査判定が出ました。これまで特定の項目で要検査や要経過観察判定は毎年出ていましたが、便潜血って聞くとさすがにいろいろ心配になりましたね。検査は大腸カメラですが、初めての経験でしかもわりと大変だったので、誰かの参考になればと思って書きます。

 

検査1週間前

いろんなブログで大腸カメラ検査の経験を書いてくれてる人がいたのでざざっと見てみると、前日夜からお尻から水が止まらないとか1時間ごとにトイレにこもるとかの話がたくさんありました。私は家から検査を受ける病院まで1.5時間かかるので、 こりゃ電車で漏らすな…と思い、検査前日から個室に入院させてもらうよう病院にお願いしました。選択肢としては下記の3つですね。

  • 検査前日から入院する
  • 頑張って電車で漏らさないよう我慢する
  • 大人の紙おむつをはいて当日電車で行く

検査前日

11時から入院受付で事務手続きを済ませて病室に入りました。検査前日から食事制限が始まります。食べちゃダメなものとして、食物繊維の多い野菜、脂っこいもの、海藻などがあります。ただ入院しているので、その辺りは病院側が管理してくれて食事が出されます。
で、病室に入ってしばらくして12時になって昼食の時間になり、出た食事がこれです。ここから自分との戦いが始まりました。

f:id:nasrinjp1:20180121222046j:plain

うん、おやつと間違えてるのかな… さすがにこれではお腹が満たされないな…
でも看護師さんに聞いたらこれが昼食だというので、美味しくいただきました。食べた気がしないですけどね。

で、病室でしばらく仕事してたら、3時のおやつが運ばれてきました。

f:id:nasrinjp1:20180121222155j:plain

わー、久々のビスコw しかもジュース多いなw が正直な感想でした。もう昼食とおやつが入れ替わっててもわかりませんね。水やスポーツドリンクは飲んでもいいとのことだったので、おやつ以降は水を飲んで空腹をしのぎました。

6時に夕食がきました。暖かいどんぶりが来たので、やったーお米ー!って思ってふたを開けたらこれです。

f:id:nasrinjp1:20180121222217j:plain

ものすごいショックでしたね… この時ほどお米粒が恋しいと思ったことはありませんでした。

 

服薬の始まり

夜8時から薬というか腸を綺麗にする飲み物や下剤を飲み始めます。最初はスポーツドリンク的な飲み物でした。

f:id:nasrinjp1:20180121222240j:plain

ちょっとレモンっぽい風味の味で美味しかったです。というかたぶん何を口にしても美味しく感じる状態だったと思います。続けて9時くらいに緑色の錠剤の下剤を飲みます。名前は「ヨーデル」。なかなかのネーミングやなと思いましたね。

で、9時半頃から、お尻から茶色い水が際限なく出てくる状態が始まりました。お腹は痛くないです。ただお尻から茶色い水が出るだけです。だいたい30分から1時間ごとにトイレに駆け込みました。寝てる間も1,2時間ごとに便意を感じてトイレにダッシュです。もうすっきり寝られませんでした。

 

検査当日

朝起きてしばらくすると看護師さんが1Lの飲み薬を持ってきました。モビプレップです。

f:id:nasrinjp1:20180121222313j:plain

これを1時間かけてゆっくり飲み干します。薄味で美味しかったです。もうなんでも美味しかったと思います。
そこからもお尻からの水は止まりません。この時に、入院の選択肢を選んでよかったと心から思いました。絶対電車で漏らしてた自信があります。

しばらくしてお尻からの水が透明になったことを看護師さんに見届けてもらい、検査の準備が完了です。

 

検査

お昼の2時半くらいにようやく検査の順番が回ってきました。お尻の部分がパカっと空いている紙パンツに履き替えて検査の部屋にいきます。

左を向いて体操座りした格好で寝た状態で検査されます。最初に肛門周辺とちょっと中までゼリー的な何かを塗られます。これがすでに気持ち悪い… そしていよいよカメラの挿入です。

肛門入り口通過時は気持ち悪かったですが、その後は腸の曲がり角通過する時だけ弱い腹痛みたいなのが来たくらいでほとんど苦しさや痛みはありませんでした。自分で自分の腸の中の画像を見ながらグリグリされます。だいたい15〜20分くらいで検査終了です。

検査が終わって病室に戻ってしばらくすると担当医の方が報告に来てくれました。結果は異常なく腸も綺麗でした。健康診断の便潜血は、肛門付近できつく拭きすぎたか何かで出血したんでしょうね、とのことでした。

で最後、検査を頑張ったお礼に昼食を持ってきてくれました。

f:id:nasrinjp1:20180121222436j:plain

このさけ雑炊がものすごく美味しいかったです!もう本当にお米を食べられることに感謝です!

 

まとめ

自分の腸の画像を見ることはなかなかないので貴重な体験でした。
でもできることならあまり何回も体験したくないので、これからは優しくお尻を拭こうと思いました。

EBS のプレウォーミングがある時ない時 [cloudpack OSAKA blog]

あけましておめでとうございます!ナスです。
約3か月ぶりの記事になっちゃいました…

さて、皆さんは EBS のプレウォーミングをご存知でしょうか?
普段から AWS で EC2 を運用されてる方ならご存知かもしれませんね。簡単にいうと、イメージバックアップから EC2&EBS を復元した後の初回アクセスはディスクアクセスが異常に遅くなるので、事前に処理して元通りの速度に戻すことです。詳細や実際の対応方法は AWS ドキュメントに書いてますので、読んでみてください。 docs.aws.amazon.com

ただ、どのくらい遅くなるのかがいまいちわからないので、プレウォーミングする前とした後でパフォーマンスを比較してみました。

 

-- テストした環境 --

インフラ環境

インスタンスサイズ:m4.large
EBS サイズ:50 GiB
EBS タイプ:gp2 (汎用 SSD)
OS:Amazon Linux 2.0 (2017.12) LTS Release Candidate
RDBMSPostgresql 9.2.23(インストールしただけの状態)

パフォーマンス計測用データ

↓この SQL で適当に作りました。

create table testtable as select s, md5(s::text) from generate_series(1,10000000) s;
select datname, pg_size_pretty(pg_database_size(datname)) from pg_database;
  datname  | pg_size_pretty
-----------+----------------
 postgres  | 718 MB

 

-- 測定結果 --

テスト環境を作った直後

事前に準備されている AMI から作成した EC2 インスタンスはプレウォーミングが必要ないので、ひとまずこれを通常時のパフォーマンスとします。

dd if=/dev/xvda of=/dev/null bs=1M

51200+0 records in
51200+0 records out
53687091200 bytes (54 GB) copied, 952.779 s, 56.3 MB/s

一応、select count(*) も測定しておきます。

select count(*) from testtable;
:
815.960 ms

 

AMI 作成後に復元した EC2 (1台目)

まずは dd コマンドでプレウォーミングしつつ、かかる時間を計測しましょう。

dd if=/dev/xvda of=/dev/null bs=1M

51200+0 records in
51200+0 records out
53687091200 bytes (54 GB) copied, 1220.06 s, 44.0 MB/s

うーん、通常時のだいたい8割くらいの速度&時間ですかね。

select count(*) from testtable;
:
11139.971 ms

クエリについては 800 ms 前後のものはキャッシュからの応答時間っぽいので、ディスクアクセスのパフォーマンスはこれがベースになりそうです。実際にもう一回同じクエリを投げると、

select count(*) from testtable;
:
808.717 ms

となるので、ディスクアクセスしたクエリのベースの応答時間は約 11 秒です。

 

AMI 作成後に復元した EC2 (2台目)

今後は dd コマンドを実行せずにクエリを実行してみました。

select count(*) from testtable;
:
103002.002 ms

遅い…最初は WiFi が切れたか固まったかと思いました。が、悩んでいるうちに結果が返ってきたのでよかった…103 秒なので、プレウォーミングした時と比べてざっくり 10 倍の時間がかかっていますね。一応、もう一回クエリを投げると、

select count(*) from testtable;
:
814.876 ms

と 1 秒未満で返ってきたので、ちゃんとキャッシュされたようです。

 

再起動や停止/起動ではプレウォーミングは必要か

ここまできたらちゃんと確認しないと気がすまないのでやってみました。
まずは dd 実行後の EC2 インスタンスを再起動して、クエリを投げてみました。

select count(*) from testtable;
:
11130.247 ms

dd 実行後の数値とだいたい同じですね。今度は、EC2 インスタンスを停止してから起動してみました。

select count(*) from testtable;
:
11148.881 ms

うん、さっきとだいたい同じ数値ですね。というわけで、EBS プレウォーミングはバックアップ用途で作成した AMI や EBS スナップショットから復元した場合に限りしたほうがいい、ということがなんとなくわかりました。(他にもプレウォーミングが必要な場面はあるかと思いますが、パッとでないので…

 

まとめ

EBS プレウォーミングをしないと、通常運用時の 10 倍の時間がかかってしまうことが確認できました。10 倍はあくまで今回のテスト結果なので、実際のところは環境やデータサイズ等によって変わると思うので、一回くらいはテストしておきたいところですね。
障害発生時などで EC2 インスタンスを AMI から復元することがあると思いますが、復旧できたと思ったら今度はパフォーマンスが低下しすぎて慌てふためく、なんてことも想像できますね…
そんなことにならないよう、障害からの復旧手順に EBS プレウォーミングを組み込むか、パフォーマンス低下することを見越してなんらかの手を打つか、初回だけだと思ってでんと構えるか、とにかくこれは知っていることが重要だと思いました。頭にこのことが入っていれば、何かあってもなんとかなるんじゃないでしょうか。