Akitsushima Design

手順

粉は中細挽き〜中挽き

フレンチプレスで淹れる場合には少し粗めくらいが良いという。粒度を粗めにすることで、雑味を少なくしたいからだと思われる。

今回はサイフォンを再現する。抽出時間は短くなるため、粉が粗いと味が薄くなってしまうことが懸念される。ドリップやサイフォンで淹れる場合と同じくらいの中細挽き〜中挽きでよい。

スーパーで売っている粉は普通中挽きくらいだと思うので、それをそのまま使っても良いはず。

事前にビーカーをよく温めておく

サイフォンの抽出温度は、90〜93度程度だという。フレンチプレスだとビーカーを温めていないと湯温が下がってしまう。これを防ぎたい。

温めた場合と温めていない場合の温度の違いは、この記事の最後に調査結果を示した。

沸騰しているお湯を2〜3回注いでから捨てる。

抽出時間は1分〜1分30秒

フレンチプレスは普通4分と言われる。一方で、サイフォンの抽出時間は40秒から1分30秒と言われる。

サイフォンの手順では、抽出時間が長いと雑味が出て美味しくなくなってしまうという説明があった。サイフォンでは高温で抽出するため、成分が抽出されやすい

お湯の量はちょっと少なめに

抽出時間が短いのでお湯が多いと味が薄くなってしまう。少し粉の配分を多めにすることで味を濃くしたい。コーヒー粉のてっぺんが300mlの線に来るようにする。お湯の分量で言うと恐らく280mlくらい。

作ってみると

フレンチプレスの普通の手順で淹れるコーヒーに比べ、あっさり目のコーヒーが作れる。雑味は確実に少なくて飲みやすい。

サイフォンは持っていないので比較はできないが、ドリップに近い飲みやすい口当たり。

粉っぽさはあるが、雑味が少ないので気にならない。粉っぽさは美味しさへの影響はそんなにないのかなと思う。個人的にはカップの底に溜まっている粉は濃い味がして美味しいと感じる。

味が薄い場合は、たいていお湯が多すぎるか、時間が短すぎる場合だった。

この淹れ方を見つけてから、毎回これで淹れるようになった。 時間も短く、美味しいコーヒーが淹れられるので気に入っている。

向いている/向かないコーヒー

この淹れ方が向いているのは、しっかり苦味があるタイプのコーヒー

タリーズ ハウスブレンド

UCC ゴールドスペシャルブレンド

一方、苦味の少ないコーヒーの場合は薄くなりすぎてしまう。その場合は4分間抽出したほうが美味しい

UCC ゴールドスペシャル プレミアム フルーティウェーブ

ほかに試してみたこと

粉を振るう

細かい粉が美味しくない原因という説明を目にし、標準的な4分の抽出時間で試してみた。 粉っぽさは軽減されるものの、雑味はそこまで減らないと感じた。

湯温を85度程度に下げる

高温で抽出することで雑味が出やすくなっているのではと思い、少し低めの温度で（4分間）抽出してみた。 少し雑味が減ったような気がするが、やはり成分が強く抽出されているような感じを受ける。

温めない場合と温めておいた場合のビーカーの温度変化の違い

サイフォンの抽出温度は、サイフォンコーヒーの抽出温度はいったい何度？｜COFFEE ROASTERY 101|コーヒー豆の通販・オンラインショップと河野式コーヒーサイフォン稽古⑦温度と玉鎖 - 金澤屋珈琲店本店ブログによると、90度〜93度くらいになるらしい。

フレンチプレスでも同じくらいの温度で抽出をするため、ビーカーを温める手順が必要だと考えた。ビーカーを温めることの効果を検証するためにちょっとした実験を行った。

条件

コーヒ粉は入れない。ビーカーとお湯のみを使う。

ビーカーに蓋（フィルター）をセットしない。熱が逃げやすい条件であることに留意。

室温: 17度程度。ビーカーの温度も同程度と推測。

フレンチプレス: ハリオ ハリオール・7 2杯用 (THSV-2-HSV)

温度計: タニタ TT-533。ビーカー内部に温度計を入れ、縁に立てかける。

計測: お湯を注ぐ直前を0秒として、5秒おきに計測

結果

ビーカーを事前に温めない場合

ビーカーの温度は室温と同じ17.5度

沸騰したてのお湯を注ぐ

ビーカーを事前に温める場合

沸騰したてのお湯を2回注いでから捨てて温める

温めた直後のビーカーの温度は不明（50度以上？）温めてから温度計をセットしたため、正確な温度は不明

わかること

温めた場合と温めない場合を比べると、3度程度の湯温の差が生まれることを読み取れる。

温めない場合は1分30秒経過時点で90度以下になってしまうのに対して、温めた場合では1分30秒経過後も90度以上の湯温を維持できている。

考察

上記のサイフォンの湯温を調べた記事では、抽出の間（サイフォンは上部ボールにお湯が移動している間）、90度〜93度を維持している。フレンチプレスでビーカーを温めることは高い温度を維持できることにつながるため、サイフォンの淹れ方を再現するという点で効果があると考えられる。

サイフォンでは93度程度で抽出を始める一方で今回紹介した淹れ方では沸騰直後のお湯を使うため、コーヒー粉に触れるお湯の温度が高くなりすぎてしまう。サイフォンの味を再現するという点では好ましくない。

キャンドゥに行く

キャンドゥだと、いつものイカリソースが手に入ります。 何店舗か見てみましたが、割とどこでも置いてます。 とんかつソースとウスターソースは普通に買えると思います。 なお、サイズはミニサイズです。

少なくとも2017年時点で見かけていて、今でも置いてるのを確認している。Twitterでは、キャンドゥで取り扱ってるという2009年頃の投稿を見つけられた。

ダイソーに行く

ダイソーでも売っています。 こちらもいつものイカリソースが手に入ります。 サイズはミニサイズです。

ローソンストア100に行く

ローソンブランドのソースが置いてあって、製造者はイカリソースと表示されています。 ローソン版は買ったことないので味はわからないですが、少なくともボトルは同じに見えます。

あまり見かけない中濃とお好み焼きソースもおいてあるのが面白いですね。

これは割と最近に気づいたので、いつ頃から置いてあったのかはわからないです。 Twitterには2011年頃にボトルを見つけたという情報があります。

カゴメソース

店舗 ラインナップ 一部スーパー ウスター セブンイレブン セブンイレブン版（とんかつ、中濃）

一部のスーパーで入手できます。 具体的な店舗は忘れてしまったので、見つけたら追記します。

セブンイレブン版は通常版とは味が異なります。

（2022/12/05追記）セブン版のとんかつソースを買ってみましたが、酸味が薄い感じがしました。通常のカゴメソースの味ではないと感じました。ラベルを見ると「塩分30%カット」との記述があり、15ml当たりの食塩相当量は通常のカゴメとんかつソースの1.0gと違い、0.65gでしたカゴメの公式からこれに相当する商品がないかを少し調べてみましたが、見当たらず。例えば「有機野菜と果実使用」は30%カットですが食塩相当量は0.7g、エネルギーも27kcalと異なります。共同開発製品と考えたほうが良さそうです。なお、原材料名は「野菜・果実（トマト（輸入）、りんご、にんじん、たまねぎ、マッシュルーム、にんにく）、醸造酢、糖類（ブドウ糖、砂糖）、食塩、アミノ酸駅、香辛料／増粘剤（加工デンプン、タマリンド、キサンタン）、香辛料抽出物、（一部にタイズ・りんごを含む）」。製造はカゴメ上野工場。タマリンドが原材料に明記されているのですが、カゴメのレストラン向けの商品のものに見られます。マッシュルームも入っているようです。通常のカゴメソースの「野菜（その他）」にもマッシュルームが含まれているのかは謎です。

（2022/01/18追記）中濃ととんかつソースはセブンイレブンで手に入ります。ラベルは違うが、製造元はカゴメソースでした。

（2021/12/13追記）カゴメのウスターは何かおいてるスーパーがたまにあることを発見。

（初稿）なかなか見つからなかったです。とんかつソースとウスターソースはほぼ見たことがないです。中濃ソースなら、品揃えの豊かなスーパーで手に入りました。帰郷したときに買って持って帰るのが良いのかもしれません。

おたふくソース

お好みソースなら割とどこでも手に入ります。 他のものは見たことがありません。

オリバーソース

どろソースだけは、なぜかとにかく置いてあります。 他のオリバーソース製品は関東では見たことがありません。

キッコーマン

たまにおいてあるのを見ます。

コーミソース

def add_one_optional(opt_val) opt_val&.yield_self {|val| val + 1 } end p add_one_optional(1) #=> 2 p add_one_optional(nil) #=> nil

なお、Rustだとこういうイメージ:

fn add_one_optional(opt_val: Option<i32>) -> Option<i32> { opt_val.map(|v| v + 1) } fn main() { println!("{:?}", add_one_optional(Some(1))); // Some(2) println!("{:?}", add_one_optional(None)); // None }

yield_selfというメソッド名が長くて打ちにくいし、見た目もそこまで綺麗ではない。 しかし、役立つシーンシーンはある。 例えば、ハッシュマップから要素を取り出し、見つかったら その要素のメソッドを呼び出すというようなシーンはあるだろう。

極太麺ペペロンチーノ

#飯飯飯 #しゅうすい飯 極太麺ペペロンチーノ pic.twitter.com/cxbT5CFiOh

— Сюусуи (@syusui_s) 2017年12月10日

引っ越ししてから料理やるぞ！と思っていたけれど、面倒臭くて七割ぐらいがパスタになってしまった。 パスタを作ったことある人は分かると思うが、パスタを作るのはめっちゃ楽。 麺茹でて、その間に具を作ってという感じで、15分程度ですぐ作れる。日本で言うなら焼きそばのノリでちゃっと作れる。 乾麺なので全然腐らないというのも、一人暮らしであんま飯作らないよという人にも嬉しいところ。

この間、スーパーに行くと珍しいパスタが売っていた。

https://www.amazon.co.jp/dp/B00HH0C3F6

※Amazonでは、1200円だがスーパーでは、200円程度である。

茹で時間15分という、パスタの時短という利点を完全につぶしている。 以前は、1.3mmのフェデリーニを愛用していたが、 あえて対極に位置するようなのも面白い面白いのでは無いかと思い、買ってみた。

毎回、レシピは適当で、大体ぐぐって上に出てきたヤツを参考にしている。 そんなに面倒な行程はない。

超簡単！！本格！！ペペロンチーノ☆★ by 料理好きBOY君 【クックパッド】 簡単おいしいみんなのレシピが280万品

絶対にうまい！ペペロンチーノ レシピ・作り方 by uzuratukune3｜楽天レシピ

ペペロンチーノのレシピ・つくり方 | キッコーマン | ホームクッキング

オリーブオイルは、安物を買ってめちゃくちゃマズかったという失敗から、そこそこ美味いヤツを買って使ってみている。

Amazon | ゴヤ エキストラヴァージン オリーブ オイル UNICO 500ml | イマイ | 食品・飲料・お酒 通販 アフェリエイトではない

いい値段するので、気軽にはおすすめできない。スーパーの特売で1300円弱に下がっていたので、思わず買ってしまったのだ。元は、1800円程度。

食べてみた感想だが、太麺だとパスタというより、焼きうどん食っているのでは？という気分になる。結構味濃い目にすると、いい感じだった。 パスタではなく、うどんが食いたいならオススメです。

ハンバーグ

#飯飯飯 #しゅうすい飯 ハンバーグ pic.twitter.com/Emd8V7DMuA

— Сюусуи (@syusui_s) 2017年8月6日

以前はひき肉をストックしていて、麻婆豆腐を作りまくっていたが、 何度も食べるうちに飽きてきた（のと、さわやかのハンバーグが美味そうだった）ので、ハンバーグにチャレンジすることにした。 豆腐ハンバーグという変種は以前作ったことがあったが、まともなハンバーグはちゃんと作ったことはなかった。 反面を焼こうとひっくり返して、ケチャップ肉そぼろになってしまうというミスを犯してしまってから、ハンバーグは難しいという印象しかなかったのだ。

今回のレシピはこれだ: ふっくらジューシーハンバーグのレシピ・作り方 | 合いびき肉 【AJINOMOTO PARK】

味の素のレシピのパン粉、卵2倍ぐらいでやった

— Сюусуи (@syusui_s) 2017年8月6日

今回は情報を集め、

タネを作る際は、ちゃんと空気を抜く

レシピの卵とパン粉を2倍にし、牛乳を大さじ1-2程度にする

を実践した。

実際、初めての割にしっかりしたのができた。パンを増やした分、パン感が出てしまったが、気にならない程度には許容範囲だった。

イラスト

昔よりは上達してきた気がします。

https://twitter.com/syusui_s/moments に絵のまとめを置いてます。

小傘ちゃん pic.twitter.com/Hak2I2R3Ka

— Сюусуи (@syusui_s) 2017年12月17日

うーやよ途中 pic.twitter.com/cA0kOA0FgL

— Сюусуи (@syusui_s) 2017年12月16日

のじゃー pic.twitter.com/RVvZR7icNV

— Сюусуи (@syusui_s) 2017年12月5日

作ったソフトウェア

syusui-s/mcnotify-rust: Minecraft status notifier

マイクラのサーバの状態を随時報告してくれるヤツです。 RCC Craft Status(@RCC_Craft)さん | Twitterの本体です。

Rustで書いてみましたが、Rustは早いし、綺麗に書けるし良いなという印象です。

syusui-s/esper: Typing software written in ECMAScript

タイピングソフトっぽいのをES6で作ろうとしましたが、未完成です。 Fluxっぽいのを自作しようとしてみたり、ES6 Module（.mjs）を使ってみたりしています。 ES6 Moduleを使っているため、ちゃんとファイルに分割されています。 新しいブラウザであれば、mjsがそのまま動くと思います。

https://syusui-s.github.io/esper/

今のところ、HTTP/2 Early Hintみたいな仕組みでもないと、mjs使うと遅いなぁという印象です。 mjsからEarly HintやサーバサイドPushのリストを作るようなやつが出てくるのではと予想しています。

Rustの印象

Rust良いよね、ここ微妙だよねという話です。 ※初学者なので、間違いがあるかもしれません。

データ型、インターフェース、実装の分離

データ型（struct, enum, union）と、インターフェース(trait)と、実装(impl)が完全に分かれています

Haskellだと、多分data, class, instanceに該当します(Haskellよく知らない)。

継承はできない

継承はインターフェース(trait)だけという割り切った設計がされています

Effective Javaでも「継承よりコンポジション」という話があるように、コンポジションでの設計を推進してくれます

依存ライブラリの管理ができる

公式のCargoがあれば、依存ライブラリを管理できます

C, C++しか触ったことが無かったので、ELF吐ける言語では扱いやすい印象を受けました

Golangもありますが、とんど触ったことないです

コンパイル速度は体感的には遅い

Intelの初代Atomでmcnotify-rustを依存ライブラリを含めてコンパイルさせると、少なくとも30分以上

今使ってるマシンだと、1分程度？

言語仕様

C++11以降を知っていると理解が早かったですが、簡単ではないです

特に所有権(move)は知っていてよかったと思いました

本当は怖くないムーブセマンティクス - yohhoyの日記（別館）

あと、スマートポインタ

一読していないのでオススメできるかわからないですが、C++11スマートポインタ入門 - Qiita

周りの人（2, 3人）に聞くと、ムズいとのこと

C言語しか知らない状態でC++を学ぼうとしたとき程度に知識の差があるとしたら、やっぱりムズいです

Haskellも若干かじってると、関数型チックなところあるなと感じるかもしれません（traitが型クラスに似てるなとか、パターンマッチまんまそれだよねとか）

Rustの資料としては、

公式サイト: プログラミング言語 Rust

英語読むよ、Google翻訳使うよという人は公式の入門書2つ

The Rust Programming Language

手を動かしたい人向け: Rust By Example

少し古いですが、公式入門書の翻訳版。全く参考にならないわけではないですが、英語版が良いと思います。

プログラミング言語Rust

Introduction | Rust by Example

Rustの良さについて: Rustは何が新しいのか（基本的な言語機能の紹介） - いもす研 (imos laboratory)

APIドキュメントは公式のやつがしっかりしている:

パターン・アンチパターン集: rust-unofficial/patterns: A catalogue of Rust design patterns

書籍: オライリーから英語の本が出てます

という感じです。

https://rust-jp.herokuapp.com というのがあり、そこに行くと色々と情報を得られます。

ISUCON

チームメンバの二人の記事:

予選

そして人権を取り戻した(ISUCON7予選突破したぞ!!!) - 雑な話

本戦

ISUCON7本戦で人権を失いました(1年ぶり2度目) - 雑な話

予選

1日目の2位、全体7位で予選通過しました。

書き起こすのも面倒なので、当時のメモをそのままはっつけます。常体なのは許してください。

開始前に便利スクリプトを組んで使うつもりでいたけど、結局あまり使われなかったっぽい。 SSHの鍵配るヤツだけめっちゃ役に立った。

motさんが司令塔とミドルウェア、僕とabcang君がアプリケーションみたいな感じでやっていた 具体的にいうと、motさんが色々計測して、どこがボトルネックなのかを探してくださり、 それを元に二人が作業するみたいな感じ。

最初からベンチで /icons が遅いと怒られまくっていたので、そこを直すのが僕の担当になった。 で、画像がDBに保存されているの、pixiv社内ISUCONでもあったよね、怪しいよねみたいな話になり、 DBから1から1001番までの画像をcurlで取得して保存するスクリプトを組んで、保存した画像を /publicに置いて、静的ファイル配信をした。 nginx の try_files でとりあえず雑に、/publicに置いてるのを優先して読んでいき、そこに無いんならアプリケーションの方に飛ばすみたいな処理に変更。 こうしておけば、新規画像の追加、参照処理は元の実装に飛ぶので、とりあえず静的ファイルにする効果見るならこれで良いだろうというのでそうした。 その間、裏でmotさんがいい感じにキャッシュの処理も入れたほうが良いんじゃないかということで、設定していただいた。 このあたりは、P社の社内ISUCONで似たようなことをやっていたお陰で割とスムーズにいった。 ここで結構スコアを伸ばせて嬉しかった。

DBへの書込みも遅いはずなので、ローカルに置いてしまおうということになった。 しかし、ローカルに置くとAppサーバ複数台になった時にどうすんの、 つまり、App2の方に書込みが合った時に、App1からどう参照するかというところで、 rsync使うのかなど案が出たけど、とりあえずApp２台で相互に参照するようにするのが良いんじゃないということになった。 つまり、App1になければApp2を見に行くみたいな処理になった。逆も然り。

で、とりあえず雑に File.write でファイルに書き出すようにして、App一台でどれぐらい性能出るか見るとめちゃくちゃスコア出てチームで歓喜した。 既にファイル存在するならwriteをスキップといった処理もできるなーと一瞬思ったけど、しなかった。 後から知ったが、nginxはファイルの更新日時見ているみたいなので、この辺ちゃんとやってないとスコアでないっぽいと聞いた（全然この辺の知識見てないので詳細不明） 雑にやったお陰で実は命拾いしていたっぽい。

相互参照どうやるかなーというところで、若干詰まったが、nginxの設定ミスっぽく、motさんがシュッと修正して事なきを得た。 で、この辺でabcang君のN+1改善など色々あって、19万点ぐらい出た。

よく思い出すと、nginxにアプリケーションサーバのレスポンスキャッシュできたので、それも詰め込めばもっと画像周りでスコア出せたんじゃないと思った。 nginxのワーカープロセスとかも上手いことできたのではないかとかある。

本戦

ISUCONは本戦に参加し、結果は18位でした。

今回の問題はCookie Clicker的なやつです。Cookie Clickerのクッキーを、椅子で置き換えた感じです。 普通のCookie Clickerとは違い、複数人で一つの椅子を協力して増やすことができるようになっています。 いつもと違う特徴的な部分は、WebSocketでの通信があるということで、これのお陰でプロファイラが動かず、焦りました。

なお、攻略方法については、こちら: ISUCON7本選問題の解説と攻略 : ISUCON公式Blog

書き起こすのも面倒なので、当時のメモをそのままはっつけます。常体なのは許してください。

問題解説

オンメモリ化（部屋ごとにサーバ分け、サーバごとにオンメモリ化）

ステータスの計算のキャッシュ（現在時刻）

設備の購入の処理を最適化

多倍長整数の演算が遅いのを直す（帯域サチる）

ルームごとにサーバを一台決めてしまえば、別にシングルスレッドなので過去の情報をもたせる必要がなくなる？ addingとかもテーブルとかではなく、getAndAddみたいなAdder的なやつ使えば良いのか？redisには確かそれが合ったはずなので、 それが使える。

結果、全体で18位

やったこと

今回の問題は、Cookie Clicker的なやつ。 複数人で一つの椅子を協力して増やすことができるようになっている。 最初のプロファイリングで、mitemを毎回取ってきているのが遅いということが判明、motさんが其処を修正。

途中でget_statusが遅いということに気づきそこを担当した 戦略としては、addingやbuyingテーブルの合計値の最新の計算結果をもたせる latest テーブルを作る。 具体的には以下のようなテーブルを作ることになる

CREATE TABLE latest ( room_id VARCHAR(191) NOT NULL, time BIGINT(20) NOT NULL, total_milli_isu LONGTEXT NOT NULL, total_power LONGTEXT NOT NULL, PRIMARY KEY (room_id, time) ); -- 現時点でコミット済みの最新データ SELECT total_milli_isu, total_power FROM latest WHERE room_id = ? AND time -- ある時点での最新データをつっこむ（時間が重複したら同じ情報のはずなので） INSERT INTO latest (room_id, time, total_milli_isu, total_power) VALUES (?, ?, ?, ?) ON DUPLICATE KEY UPDATE time = time;

しかし、DBへのアクセス過多により、スコアが中々伸びない。 DBのiowaitが凄いことになっており、こいつをどうするかというのが、ここでの課題だった。 手が付けられそうなところと言えばそこぐらいしか無かったので、そこを引き続き担当することになった。 motさんがmysqlのチューニングも試してみるが、余り変わらず。

ここをRedisにも載せ替えてみたが、timeカラムでソートして取ってくるのをどうするかというところどうするのみたいな話になる。 しかし、ソートしなくてもある時点での最新の値が入っていれば、後はaddingから計算するのでそれで良いやということになり、そのまま続ける。 回収を終えてベンチを走らせるが、スコアはほぼ変わらず。むしろ、ベンチマークでエラーが発生して、スコアが下がってしまった。

その後で、そもそもの実装ミスっていることに気づいた DBに保存する際に、指数表記のまま突っ込もうとしていたため、ちゃんと復元できていなかった というわけで組んでやってみたが、結局スコアはほぼ変わらず。なぜスコアが全然

最後の方に、私の組んでいたget_statusの最新結果をテーブルに保持するような仕組みを試しに消してみると、スコアがほぼ変わらない もしやと思って、テーブルの行数を見てみると、4000件程度しかデータがない

完全に後からの推測ではあるが、この程度のデータ量では、最新の計算結果を保持したところで大きくスコアを伸ばせないのではという結論に至った。 思い出せば、この設計に変える前に「addingとbuyingに入っている件数をチェックしたい」と何度か漏らしていた しかし、結局確認せずにススメてしまったのがまずかった

他の人のエントリ

MOTさんのエントリ

阿部くんのエントリ

他の人とのエントリの差分は、詳細な経過が載っているところです。

お題

リアルタイムお絵かきチャットサービス「ISUketch」を、 多くのユーザがアクセスしても快適に使えるようにしろ！というようなお題です。 最初の段階では、Reactと参考実装、MySQLがそれぞれDockerコンテナとして、1台のホストで立ち上がっています。

経過

10:00〜11:00ぐらい？

開始直後、デプロイが上手く行かないという問題が発生。MOTさんがデプロイの方を調査することに。

僕が、Azureのリンクには、デプロイのために参考実装のアーカイブのURLが入っていんじゃないかということで、調べてみると見事アーカイブファイルが見つかる。DLすることに成功。このため、他のチームより早い段階で実装を読むのに取り掛かることができたと思う。

阿部くんに参考実装のファイルを渡して、読んでもらうことになった。

僕は、パケットキャプチャ（tcpdump）を用いて、ベンチマーカからの通信を見ようと試みた。とりあえず、apt-get install tcpdumpする。しかし、ここで通信がHTTPSということに気付く。TLS/SSL通信は、アプリケーションがNSS Key Log Fileを吐いてくれるなら、復号可能なのだが、Nginxにはそのような機能は付いていないらしい。そんなわけで諦める。

11:00〜11:30

このあたりで阿部くんが実装を読み解いてくれて、チームメンバー全員で情報を共有する。参考実装はどうやらAPIとして動いているらしく、node.jsが処理を請け負い、サーバサイドレンダリングを行うサーバとして動いているらしい。ついでに、プロファイラを仕込む。

話し合いの中、ストリーミング（Server-side Events）APIへのアクセスが多いんじゃないか？という見当をつけ始める。このあたりが完全に失敗だったんじゃないかと思う。もっと調査をしておけばと後悔している。

11:30〜12:00

そうこう話をしているうちに、分散構成にしてみようという話になった。APIへのアクセスはきっと多いだろうから、Rubyを2台構成にして、ストリーミング専用を1台、待ち受け用のh2o+node.jsを1台、DB用に1台で、5台全てを使うという構成を考える。この構成にするために、色々と手配を始めることになった。MOTさんがh2oの導入、阿部くんがMySQLの分離とRubyAPIの分離と改善、僕がストリーム処理の分離と改善という風に担当が分かれる。

MOTさんのところで、h2oまわりで色々苦戦しているようだった。

この間、僕と阿部くん（多分）は、docker-composeをいじってみたり、サーバに入って、うまい分離方法を調べるなどしていた。

12:00〜13:00

お昼ご飯を食べる。この段階であまり進捗がでていないことに焦り始める。

蟹を食って取り敢えず落ち着く。 https://pic.twitter.com/lUv9l7kd3K

ご飯を食べながら僕と阿部くんがDBに繋ぎに行くようにする。

13:00~14:00

なんか色々話し合っていたように思うがあまり覚えていない。

この辺でh2oのコミットがあるが、動かなかった気がする。あるいは中々スコアが出なかったか。よく覚えていない。

14:00〜15:00

僕は、お絵かきルームに入室している人数の算出処理をRedisに移してみる。Redisのソート済みセット型を用いると、データをソートされた状態で保存できる。このとき、閲覧時間順でユーザをソートしておけば、閲覧しているユーザをすぐに見つけることができる。具体的に言うと、ユーザが閲覧時間を更新する度にZADD(ルームID, 時間, CSRF_TOKEN=ユーザのトークン)を行い、閲覧人数が必要なときにZCOUNT(ルームID, 3秒前, 現在時刻)とする。こいつが上手く動いてくれていたらスコアを稼げていたかもしれないが、今となっては何処が問題だったのかよくわからない。

阿部くんも、N+1問題を修正する。

僕はジョブ数増やしたりしていた。

MOTさんはサーバ周りをいじっていたよう。よく覚えていない。

このあたりでh2oを諦めて、nginxに乗り換えた記憶がある。うごきだすようになったので、即座にベンチマークにかけてみる。しかし、参考実装を下回るという結果が出る。これで僕やMOTさんあたりは、かなり焦りだす。阿部くんも多分。確かついでにHTTP/2を有効にした気がする。

この辺でDockerまわりで時間食ってて辛いということを言っていた気がする。昼間あたりに隣のチーム（優勝チーム）がDocker潰したぜ！って言っていたのを思い出す。

16:30〜17:00

このあたりはコミットログがないので、多分サーバに直に修正加えたりとかしていた。

この辺からURLのIDと表示上のIDがずれる問題に遭遇する。調査に取り掛かるが誰も結局わからなかった。DBを潰して作り直して対応。

17:00~18:00

阿部くんがN+1を修正する。

色々変更を加えたがスコアが全然伸びないので、変更途中のをstashするなりして、とりあえず動くものを提出しようということに。それで提出。最後に見たスコア（17:58:57）は、3865点。最初の参考実装の約4000点を下回ったまま、競技が終了。

反省

反省することは探せば無限にありますが、思い返して致命的だったなあと思うのは次の2点。

最初の調査・計測を十分にせずに、分散処理の構成を考えてしまった。確か、最初に参考実装をRubyに切り替えてから、ベンチマークを回したり、プロファイリングで詰まってるところ探したりとかあまりできなかったような記憶がある。他のチームの本戦について書いた事を見ていると、ある程度高速化してからサーバの構成を考えるという流れが多くて、そのほうが問題点探すのが楽だし、分散処理の構成を考えるのは、最後のほうが良いなと思った。

面倒くさいといって、SVGの高速化をしなかった。これは僕が面倒くさいと言ってしまったのが完全に駄目だった。今思えば、雑な実装で良ければ、Rubyの方にに直に書くこともできたのでそうしたら良かった。時間がなくて焦っている中でも、面倒臭がらずに効果が出る部分はちゃんとやったほうが良かった。

ナウい技術を勉強しておく。Dockerは使ったことがあるので使えると思っていたけれど、Docker関連で躓くことは実際多かった。少しイメージをいじると、反映に時間が掛かったり、上手く変更が反映されなかったり。Dockerを使うメリット・デメリットを知っておくべきだった。あとは、Reactのサーバサイドレンダリングが重いということも知っておくべきだった。

次回にむけて

本戦ではスコアは取れませんでしたが、色々な学びがありました。MOTさんによると、次回はチーム新卒で行きたいとのことですので、それまでにしっかりと勉強したいと思います。次回は、

十分に調査を行う

面倒くさくても効果が出るならやる

ナウい技術にも手を触れておく

分散構成を考えるのは最後の方

ということに気をつけて、取り掛かりたいです。

最後になりましたが、ISUCON 6を開催してくださった運営者の皆様、非常に勉強になる良い経験ができました。ありがとうございましあてい

講義

講義は、情報倫理とバイナリ、ネットワークの3つに分けて行われました。 情報倫理の講義では、法律や脆弱性報告の方法など、興味深い話題が多く、 実際には気をつけるべきことが多くあることを知りました。

実技の講義では、まともに分かっていなかったツールの 使い方を学ぶことができて、とてもためになりました。 楽な方法やツールがあることを知っておくと、本番でかなり役に立ちそうです。

CTF (Write-up)

仮想マシンのWindowsを立ち上げると、 不思議な力で死ぬことが2度もあったので、 実機Linuxの方で挑戦しました。 仮想マシンの使用量をを少なく設定しないと 死ぬぐらいメモリが窮屈だったので、そのあたりが影響しているのかも……。 というわけで、.exeは全部スキップしました……。

今回は、5位になることができました（1400ポイント）。 解けなかった、Bin 300, 400, 500とWeb 500についてはWrite-upを載せてません。

Net 100 『Insecure Protocol』

pcapファイルを落としてきて、 WiresharkでFollow TCP Streamすると、 Telnetのログインの様子が記録されているようでした。 見てみると、パスワードがフラグになっていました。

Net 200 『Insecure Protocol 2』（解けなかった）

これもpcapファイルが渡されます。 同様にWiresharkでFollow TCP Streamすると、 こちらもtelnetのログインの様子が記録されていました。 ログインした後にフラグの部分が表示されているのですが、 パケットに載っていたフラグは、ctf4b{******************************} となっており、このままでは通りません。 IPをよく見ると、ローカルネットワークのIPアドレスだったので、 telnetでつなごうとしたのですが、何回やってもつながらなかったので、諦めました。 他の方はこの方法で解けているようですので、僕の環境が悪かっただけだと思います。

Net 300 『File Transfer Protocol』

これもpcapファイルが渡されます。 WiresharkでFollow TCP Streamすると、FTPの通信でした。 通信内容を見てみると、1.txtと2.zip、3.txtの3つの ファイルを転送しているようでした。 このファイルが怪しいと思い、パケットを探していました。 ここで、フィルターのところにtcp.stream eq 0が入っていることに気づかずにいました。 ファイルの転送部分だけは、別のstream?のようなので、これでは見つからないです。 フィルタを解除し、自力でそれっぽいパケットを探すと、 フラグらしき文字列が見つかります。1, 2, 3で分割されて転送されていました。 1と3は平文だったので、見てみると ctf4b{This_communication_isとencrypted.}だったので、 _notが間に来るだろうと予想ができます。 また、2.zipも短すぎて中身が見えていてしまっていました。 これらを繋ぐとフラグになります。

ctf4b{This_communication_is_not_encrypted.}

なお、最後の答え合わせで、ftp-dataでフィルターすると ファイル転送がすぐに抽出できて良いという解答例があがっていました。

Net 400 『This quiz is a NETWORK challenge』（解けなかった）

exeファイルが渡されますが、環境を持ってなかったので飛ばしました。

Net 500 『OLD Communication』（解けなかった）

誰も解けなかった問題ですが、作者の方がネタバレをされていたのと、 途中までは行けていたので、途中まで載せてみます。

これもpcapファイルですが、ファイル形式が異常なため開くことができません。 エラーは、「network type 16777216は分からない」と言っていて、 何でこんなにキリが良い数字なのかと疑問に思いました。 また、fileコマンドで見たファイルのバージョン情報も変だったので、 ヘッダが怪しいと思いました。ですが、バイナリいじっていちいち直すのも 面倒だったので、ヘッダいじるのはやめました……。

xxdとlessを使ってファイルを眺めてみると、IRCの通信ということは分かりましたが、 肝心のIPのパケットを読み出す術がわからず、諦めました。

Web 100 『Can you login as admin?』

ログイン画面がでてくるので、guest:guestで試しに打ってみると、 HTTP GETでログインしていることがわかります。 つまり、リクエストのパラメータがURLに入っています。 ログインといえば、事前資料のほうに載っていた SQLインジェクションが怪しくなります。 password=' OR 1 == 1;'としてみると、フラグが入手できました。

Web 200 『Find the flag』

と表示されるので、HTTPリクエストのヘッダを見ると、 Cookieにフラグが隠れていました。 URIのエンコーディングは、ASCII文字を16進表記してるだけなので、 RubyのInteger#chr やJSのdecodeURIComponentを使うと、復元できます。

Web 300 『1M4G3 V13W3R』

画像ファイルのアップローダのようです。 上がっている画像を開いてみると、?file=というクエリがくっついていて、 怪しいと感じました。

ファイルに、/etc/passwdやindex.phpを指定しても無理だったので、 ディレクトリトラバーサルかなと疑って、../index.phpを試しに打ってみたところ、 phpファイルが表示されて、先頭のコメントがフラグになっていました。

Web 500『Univarsal Web Page(笑)』（解けなかった）

?lang=のクエリが怪しかったので、ここに..を付けてみると...

includeと書いてあるので、恐らく言語ごとのファイルを そのまま読み込んでいるのだと予想できます。 /srv/http/web500/index.phpと書いてあるので、 おそらくこれを開けばいいのでしょう。が、ボケていたのか ?lang=/srv/http/index.phpとしてしまい、 別のページがincludeされてずっと迷っていました。 結局、この方法ではincludeしているだけなので、そのまま表示されるだけです。 どうにかサーバにデータを送るか、URIを指定してやる必要がありそうです。

Binary 100 『うる星やつら』

bin100というファイルが落ちてくるので、とりあえずfileコマンドで調べてみます。 すると、「ISO 9660 CD-ROM filesystem data 'FLAG'」とででくるのでISOだと分かります。 sudo mount -o loop bin100 /mnt/cdrom/とすると、マウントができます。 中身を見ると、flagというファイルが入っているので、これもfileで調べると、 「Microsoft Cabinet archive data」ということがわかります。 Linuxだとcabextractコマンドで展開できるので、展開してみると、またflagがでてきます。 これは、fileによるとZipファイルなので、unzipコマンドで展開して、また出てきたflagを fileで確認すると、今度はjpegだったので、 画像ビューアで開いてみるとフラグが載っていました。

Binary 200 『find flag』

このスライドは、CC BY-SA 4.0で公開しますので、 ライセンスに基づいていれば、どのように利用していただいても構いません。

自動化設定の仕方

下記の設定例を参考に設定してみてください。

詳しい仕様については、READMEをご覧ください。

# これで始まる行はコメントです # 非公開設定 # 設定方法: 付与タグ タグ1 タグ2 ... # # 複数指定された場合は、いずれかに一致すると実行されます。 private R-18 R-17.9 R-15 # 完全にタグが一致したら、指定のタグを追加/削除します。 # 設定方法: match 付与タグ タグ1 タグ2 ... # # 複数指定された場合は、いずれかに一致すると実行されます。 # 別種のpattern_allは、指定されたすべての正規表現に一致すると実行されます。 # 先頭に-をつけると、すでに付与したタグから削除します。 match 響 ヴェールヌイ # パターンマッチに一致したら、タグを追加します。 # 設定方法: pattern 付与タグ 正規表現1 正規表現2 ... # # 正規表現は、JavaScriptで利用できるものと同じです。 # https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Regular_Expressions # 複数指定された場合は、いずれかに一致すると実行されます。 # 別種のpattern_allは、指定されたすべての正規表現に一致すると実行されます。 # ~1 のようにして マッチグループを参照できます。 # 先頭に-をつけると、すでに付与したタグから削除します。 pattern 艦隊これくしょん 艦これ pattern -~1 (艦これ|艦娘) pattern ~1 ^(.+)(\(艦隊これくしょん\)|\(艦これ\))$ pattern_all ~1 ^艦これ$|^艦隊これくしょん$ ^(.+)(改|改二)$ pattern けものフレンズ けもフレ|けものフレンズ pattern -~1 けもフレ pattern_all かばん(けものフレンズ) けものフレンズ かばん(ちゃん)? pattern_all サーバル(けものフレンズ) けものフレンズ サーバル(ちゃん|キャット)? pattern_all ラッキービースト(けものフレンズ) けものフレンズ ラッキービースト

経緯

pixivでブックマークを始めるとかなりの量が溜まってきて、 こういうのを見たいという時に検索代わりになるのが、ブックマークタグ。 前から付けるようにしていたのですが、 途中からまともにタグ付けするのに疲れてしまいました。

普段の自分の作業を考えてみると、

前につけたタグと同じになるようにする

他人に知られたくないものは、非公開

という割と簡単にプログラムできるものでした。