ハンドドリップでコーヒーを淹れ始めた

最近義弟がコーヒーにハマり、自宅に遊びに来てくれる度にハンドドリップのコーヒーを淹れてくれた。器具を毎回持ってきてもらうのも申し訳なかったので一式購入してみたところ、自分もハンドドリップにハマってしまった。

意外と初期投資が少なく敷居が低いなぁと思ったので、他の人に紹介する時のためにメモしておく。

最初に購入したもの

最低限必要で安価なものを選んだ。合計は6000円程度。
アイスコーヒーが好きなので、アイスもホットもいけるサーバーを購入。
特に問題なく美味しいコーヒーが淹れられたのでとても満足。

HARIO (ハリオ) V60 アイスコーヒー メーカー 2~4人用 VIC-02B

HARIO(ハリオ) コーヒーミル・スマートG 透明ブラック MSG-2-TB

HARIO(ハリオ) V60ドリップケトル・エアー 実用容量350ml 透明ブラック 日本製 VKA-35-TB

追加で購入したもの

最初はコーヒー豆をプラスチックのキャニスターに入れて保管していたが、どうやら空気に触れると酸化してしまうので良くないとのこと。
色々調べたところ、アルミの真空パックに入れて冷凍庫に保管すると長持ちするらしいので導入してみた。
1ヶ月ほど経過しても美味しく飲めているので良い感じ。

30枚入 アルミ袋 チャック付き コーヒー豆 保存 小分け 袋 真空パック 食品 遮光 防臭 ジッパーバッグ (15x22cm)

最初はフライパンとか鍋に水を入れてコンロでお湯を沸かしていたが、ドリップケトルに入れにくいし片付けも面倒だったので、丁度セール中だった山善のケトルを購入した。
温度調節は1℃ずつ出来るし、沸かすのも早く、そのまま注ぐことが出来るので大変便利。値段もそこまで高くなくコスパがかなり良かった。

[山善] 電気ケトル 電気ポット 0.8L (温度設定機能/保温機能/空焚き防止機能) ブラック YKG-C800-E(B) [メーカー保証1年]

淹れ始めると色々と美味しい淹れ方を調べるもので、どうやら微粉が味を損ねることが分かった。
最初に購入したミルはセラミック臼刃で、金属の臼刃より微粉が出やすく均一性も低くなるらしい。 なので、ステンレス臼刃でコスパが良いTIMEMORE C2 MAXを買ってみた。
実際に使ってみたが、セラミックに比べて軽い力で挽けて味も美味しくなった（ような気がする）。

TIMEMOREタイムモア 栗子C2 MAX手挽きコーヒーミル 容量30g コーヒーグラインダー ステンレス臼 アルミボディ 36段階粗さ調整可能 省力 均一 (ブラック)

他に欲しいもの

アイスコーヒー用のサーバーを買ったので、大きくて洗うのが若干手間で場所も取る。
ホットコーヒーを淹れることも増えたので、小さめのサーバーを購入するか考え中。

ザバス アクアホエイプロテイン100が美味しい

ザバス(SAVAS) アクアホエイプロテイン100+クエン酸 グレープフルーツ風味【40食分】 840g

去年からリングフィットを始めて、プロテインも飲み始めた。X-PLOSIONやマイプロテインなどを色々試したけど、一番美味しいのはザバスのアクアホエイプロテインだった。ポカリスエットやアクエリアスのような味で、個人的にはそれよりも美味しく感じた。これを楽しみに運動している時もあるので、モチベーション維持にも良い。

デメリットは、他と比べるとかなり高価なこと。常用するのは厳しいので、通常はX-PLOSIONやマイプロテインを飲んで、運動後のご褒美にこれを飲む感じにしている。

弐寺復帰して中伝を取った話

人生で一番長くプレイしているゲームは間違いなくbeatmania IIDX（通称弐寺）だ。中学生の頃にbeatmaniaと出会い、高校生でCS beatmania IIDXを初めてプレーし、専門学生のときにACデビューした。以降ゲーセンに足繁く通い、CSが発売されれば必ず購入し、社会人になった後はわざわざブラウン管のテレビ*1を中古で購入してプレーしていた。腕前に関しては、AC DistorteDで十段に合格し、それから万年十段だったので、上級者底辺みたいな立ち位置だったと思う。

そんな感じで長い間弐寺をプレイしていたが、子供が生まれてからゲーセンに行く機会が激減し、CSも新作が発売されなくなったため、弐寺をプレイすることがほぼなくなってしまった。年に1,2回ゲーセンに行くくらいで、PENDUALまではなんとか十段継続できていたが、copula以降は九段に落ちてしまい、Rootage以降は一度もプレイしていない。PC版が出ていたのは知っていたが、専コンはプレミアムモデルしかなくて高価だし、子供もまだ小さかったので音がうるさいと起きてしまうことを懸念してスルーしていた。

ゲーセンに通うことが難しいのでもう引退かなと思っていたが、少し安価な専コンが発売されたり、コロナが猛威を奮ってリモートワークになったり、定額給付金が支給されたので使い道を考えてたりと色々なタイミングが重なり、弐寺をやりたい気持ちが再燃してPC版をやり始めた。

またやりたくなって購入してもうた / 商品詳細ページ | コナミスタイル|KONAMIの公式通販サイト | 【再販】beatmania IIDX 専用コントローラ エントリーモデル https://t.co/kB2Q8cQBbb

— waniji (@waniji) 2020年6月5日

少し前までやり込んでいたスプラトゥーン2の熱が冷めていて、他にやり込んでいるゲームがなかったので、ちょっと本腰入れてどこまでいけるかやってみようと思った。最初は九段も落ちるレベルの腕前になっていたので、☆10あたりを中心にプレイしていた。1ヶ月位すると少しずつ感覚を取り戻してきたので、☆11を全ノマゲにすることを目標に掲げて、Bitを貯めては楽曲を解禁してランプを点けていった。そうして4ヶ月後に十段に合格した。

INFINITAS十段合格した pic.twitter.com/U1bGzg9Mqw

— waniji (@waniji) 2020年10月23日

☆11もだいぶ埋まってきて、ほぼほぼハードクリアが出来るようになっていた。しかし、以前よりは成長度も落ち着いてきており、これより上達するには☆12で地力を上げるしかないなと感じて、徐々に手を出していった。この頃にはモチベがかなり高くなっていて、☆12地力表をもとにクリア管理表をスプレッドシートで作ったりしていた。地力表の下から挑戦してはクリアを増やしていき、十段取得から2ヶ月後にAA穴をハードクリアした。

AA(A)をHARDしたので全盛期に戻ったと言って良さそう

— waniji (@waniji) 2020年12月19日

全盛期の腕前がAA穴ハードクリアくらいだったので、そこまで実力が戻ったことになる。ここまで来たなら本格的に皆伝を目指したいなと強く思うようになり、引き続き☆12を埋めていった。ノマゲ地力Cを全て埋め、ノマゲ地力B〜B+がそこそこクリア出来てきたところで試しに中伝をプレイしたところ、ギリギリ合格した。

弐寺復帰から7ヶ月、ついに中伝合格 pic.twitter.com/Wr9eujbY4H

— waniji (@waniji) 2021年1月23日

復帰から7ヶ月、十段取得から3ヶ月経ったタイミングだった。上達を日々感じていたためか、モチベが高いまま続けられている。PC版はCSに比べると楽曲数が圧倒的に多いので、飽きずにプレーし続けられたのも上達出来た要因の一つかもしれない。楽曲パックは半分くらいしか購入していないので、まだまだ楽しむことが出来そうだ。

ここから皆伝への道のりはかなり遠いと思うので、気長にプレーして来年中に取れたら良いなと思う。10年以上前に出来なかったことを、この歳で達成出来たらかなり面白い展開だと思うのでワクワクしている。

*1:ブラウン管テレビは液晶テレビと比べて表示遅延が少ない

複数のログファイルをtd-agentを使ってCloudWatch Logsに送る時にログファイル名をログストリーム名にする方法

ひと手間加える必要があったのでメモ。

バージョン

• td-agent v3.8.1
• fluent-plugin-cloudwatch-logs v0.13.0

方法

まずファイル名をタグに入れるために、 tag にワイルドカードを指定する。こうすることで、フルパスが tag の末尾に追加される。（デリミタは . に変換される）

<source>
  @type tail
  format none
  pos_file /path/to/pos/foobar.pos
  path /path/to/log/*.log
  read_from_head true
  tag log.*
</source>

次に record_transformer を挟んでレコードにストリーム名を追加する。tail でタグにフルパスを含めたので、ファイル名の部分以降を tag_suffix で抜き出して指定する。

<filter log.**>
  @type record_transformer
  <record>
    stream_name ${tag_suffix[4]}
  </record>
</filter>

何故レコードにストリーム名を追加するかと言うと、 fluent-plugin-cloudwatch-logs には log_stream_name_key と言うオプションがあり、ここで指定したキーの値をストリーム名に使うことが出来るため。ストリーム名に使ったキーをCloudWatch Logsに残したくない場合は remove_log_stream_name_key も有効にする必要がある。

<match log.**>
  @type cloudwatch_logs
  log_group_name foobar
  log_stream_name_key stream_name
  remove_log_stream_name_key true
  auto_create_stream true
</match>

他にも use_tag_as_stream と言うオプションがあるが、これはタグすべてをストリーム名に使ってしまう。ファイル名だけにしたい場合は使うことが出来ない。

ISUCON10予選にk02で参加して敗退しました

ISUCON10予選にいつものメンバー（kyokomi, yasu）で参加して敗退した。
最終スコアは1,188で、全チーム（468チーム）の中では129番目。
初期スコアが500前後、予選通過ラインは2,100ぐらいだったので、良いとは言えないスコアかなと......。

ISUCON10 オンライン予選 全てのチームのスコア（参考値） : ISUCON公式Blog

準備したこと

今回はNew Relicさんが無料ライセンスを提供していたので、ありがたく使わせていただきました 🙏
事前にライセンスを発行し、ISUCON9のアプリに組み込んで、どのような情報が取れるかを確認。

ISUCON10参加者向けNew Relic特別無料ライセンスが利用可能となりました : ISUCON公式Blog

当日

初動

まずはいつも通りの対応

• レギュレーションを読み込む
• ドキュメントを読み込む
• サーバにログインする設定を追加
• アプリの動作確認
• 構成の把握
• GitHubにコードをpush
• 修正入れずにベンチマークを実行

次に事前に準備したNew Relic関連を設定

• New Relic Agentを全台に導入
• アプリにNew Relicパッケージを導入

修正内容

分担しながら以下を実施

• NginxでBotを弾く
• MySQLを別サーバに移動
• INDEXを貼って /api/estate/low_priced と /api/chair/low_priced を改善
• rent, width, height などを範囲ではなくIDで検索するようにする
  • 併せてINDEXも追加
• 検索条件のjsonを毎回parseしないようにする
• estateにgeometryのカラムを追加して、なぞって検索のN+1を解消
• /api/recommended_estate/:id のクエリ改善（時間切れで修正間に合わず）

良かったこと

New Relicが便利

New Relicの画面

どこに時間がかかっているか、修正した結果どのように変化したかがとても分かり易かった。前回までは手元で集計・分析してSlackで共有していたが、その手間が省けて効率的に進めることが出来た。ただ、New Relic自体の習熟度が低かったので、活用しきれたとは言えなかったのは反省点。

毎回やっていることは詰まらず出来た

MySQLの分離、MySQLのスローログ分析などは毎回やっていて、手順もチームのScrapboxにまとまっているので、何も詰まらずに作業ができた。

反省点

MySQLの知識不足

Generated columns や Descending index はそもそも知らず、Geometry についてはヒィヒィ言いながら調べて対応したのでかなり時間がかかった。DB分割が出来ていればかなりスコアが上がったのでは......という気はするので、MySQLの知識不足がかなり痛かった。

問題解決までに時間がかかりすぎた

解説を見ていると、分かってはいたが修正が間に合わなかった事が多い事に気づいた。どの修正が一番効果的かをチームで話し合いながら進めたが、とにかく手を動かして改善をし続ける人が一人はいたほうが、結果的にスコアが伸びるかもしれない。（単純に実力不足というのもある。悲しい。）

ISUCON10 予選問題の解説と講評 : ISUCON公式Blog

おわりに

今回も楽しかったし悔しかった。
次回があればまた参加します。
運営の皆様お疲れさまでした。

ISUCON9予選にk02で参加して惨敗しました #isucon

いつものメンバーでISUCONに参加して惨敗しました。いつもどおりインフラ面を担当。
最大スコアは3,120で、最終結果は fail でした。

事前にやったこと

• チームで集まって打ち合わせとISUCON8予選を軽く解く
• Prometheus + Grafana を使うことに決めたので、使用方法を調査
• 当日やることの手順を scrapbox にまとめる (分析ツールのインストールや使用方法など)

当日やったこと

10:00-10:30

• マニュアルを読んで気になった点をまとめる
• テーブルのCREATE文やレコード数、レコード内容を scarpbox にメモ
• categories が更新されないことに気づく

10:30-11:00

• アプリケーションを触って動作確認
• 決済が動かず悩んだが、pyament-service の url が開発用になってないことに気づく
• QRコードを読み込み、発送完了に出来たことを喜ぶ

11:00-11:30

• kataribe 入れた
• hostnamectl で各サーバの名前をわかりやすくした
• MySQL を 別サーバに移し始める

11:30-12:30

• Alibaba Cloud のセキュリティグループをいじって 3306 ポートを許可する
• MySQL の bind-address を 0.0.0.0 にして動き始める
• ベンチを実行して、MySQL の slowlog と Nginx log の分析
• DBサーバのCPUが200%近かったので、DBがボトルネックと判断

12:30-13:30

• お昼ごはんを買いに行く
• 作戦会議

13:30-14:30

• デプロイしてログの分析を何度か行う
• 合間に Prometheus の node-exporter と mysql-exporter を入れた

14:30-15:30

• そろそろ campaign の値を変えておきたいねということで 1 にする
  • リクエスト傾向が変わり、Appサーバにボトルネックが移る
  • もっと早く試しておけばと後悔
• Too many open files が出たので、systemd の LimitNOFILE の設定を nginx, isucari, mysql に設定
• MySQL の max connections を増やした
• shippment service が APIGatewayError(502) で死に始める

16:00-17:00

• shipment service の status 遷移を見て、initial, wait_pickup, done は api 叩かなくて良いのではという話をする
• App 二台構成にしようとして、画像の配信でエラーになったので戻す

17:00-18:10

• 修正をしてはデプロイしてアクセスログ確認、を繰り返す

18:10

• おわり

反省点

• 各種ツールのインストールが遅すぎた。スクリプト組むなり ansible 使うなりして最速で終わらせるべきだった。
• campaign の値を変えるのが遅すぎた。単に負荷が上がるだけだと勘違いしていたのがそもそもの間違い。
• 外部サービスのチェックが甘かった。業務だと気を使うのに、ISUCONでは何も問題なく動くと信頼しきっていた...。
• App2台の構成にできなかった。画像の共有どうしようか、WebDavか、とか考えていたが、そもそも重い処理だけ振り分ければよかった。
• アプリの調査に時間を使いすぎて、インフラの改善が疎かになった。インフラ担当なので、インフラの改善をもっとすべきだった。

次回に向けて

具体的な反省点が見つかったので、次回は改善して挑みたい。悔しい。

ISUCON8本戦にk02で参加し惨敗しました(15位)

初の本戦出場、スコアは5,124で順位は30組中15位でした。
シェアボタンを有効に出来ず勝負の土俵に立てなかったので、非常に悔しいです。

当日やったこと

[10:00 - 10:30]

• ポータルサイトにログインしてレギュレーションを読む
• 初期状態でベンチ実行
• isuconユーザーに公開鍵認証でログインできるようにする
• 全台でmysqldumpを実行

[10:30 - 11:00]

• アプリケーションを操作して挙動を確かめる

[11:30 - 12:00]

• サーバの情報をKibelaにまとめる
• ベンチ前後のDBデータ件数などをKibelaにまとめる

[12:00 - 13:00]

• ランチ兼ねて作戦会議
• ここからアプリ担当(kyokomi,yasu)とインフラ担当(waniji)に分担

[13:00 - 13:30]

• MySQLをDockerから切り離して別サーバに構築

[13:30 - 14:30]

• MySQLのスロークエリを有効にしてmysqldumpslowで分析
• SHOW CREATE TABLEの結果をKibelaにまとめる

[14:30 - 15:00]

• NginxをDockerから切り離す

[15:00 - 16:00]

• Nginxで静的ファイルを配信したが、何故かレイアウトが崩れてしまい戻す
• ここで大幅なロス

[16:00 - 17:00]

• sendfile, tcp_nopush, keepalive_timeout の設定を追加
• Nginx+Appが1台、Appのみが2台、DBが1台の構成にする
• 再起動用の設定を全台に行う

[17:00 - 18:00]

• シェアボタンを有効にするもエラー多発で戻す

良かった点

• Kibelaに情報をまとめた
  • Slackだと流れてしまう情報が見やすく便利だった
• 各種計測ツールをスムーズに導入することが出来た
  • 事前練習の賜物

悪かった点

• WEBサーバ3台+DBサーバ1台という構成にとらわれすぎた
  • 想定解法がMySQLのmaster/slaveだったが考えつかなかった
• CPUに余裕があることに対し早めに疑問を持てなかった
  • 早々にシェアボタンを有効にしてボトルネックを調査すればよかった
• シェアボタンの部分開放が思いつかなかった
  • 業務で10％開放のケースはよくあるのに何故思いつかなかったのか...
• パーティションまで手が回らなかった
  • ここは気付いて後回しにしてしまったがゆえに悔しい...
• 1つ1つの作業が遅かった
  • インフラ側の作業をもっと早く終わらせるべきだった
  • 日々の鍛錬が足りない

最後に

問題、会場、運営、どれをとっても素晴らしく、有意義な時間を過ごすことが出来ました。
次回があるならば必ずリベンジします。悔しい。