ソンブレロ鍋

鍋メモ

ISUCON9 予選に参加した．

ISUCON9 予選に参加した． ISUCON とは，「いい感じにスピードアップコンテスト (Iikanjini Speed Up CONtest) 」 というコンテストで，与えられた Web アプリケーションの処理を高速化するコンテストである．

予選中の最高スコアは 13000~14000 と良かったけれど再起動後のアプリケーション起動がうまくいかず，運営による追試をパスしなかったため予選敗退した．

事前にチームでやったこと

  • 使用する言語を Go に決めていて， Go のパフォーマンス計測ツールである pprof の使い方を学ぶため， ISUCON直前 pprof特訓会に参加した
  • AlibabaCloud ECS(Elastic Computing Service)でインスタンスを作る練習
  • ISUCON7 のインスタンスを作ってみる (過去問練習の予定だったが AlibabaCloud アカウントの準備等に時間がかかりインスタンスを作ったところで終了した)
  • ISUCON8 の過去問練習 (先述した pprof を投入する練習としてよく機能した)
  • SSH や hosts などの，ミドルウェアから下のほぼ定型の変更を加えるコードの用意
    • ChatOps ツール / 計測ツール などなどの設定なども含む
      • ChatOps ツールはチームメイトが作ったもの？ (詳細を把握していない)
      • kataribe, netdata, phpMyAdmin をメインで使った
  • 当日使う git リポジトリの用意
  • 開発環境の統一
    • VSCode / goimports などの設定
  • 当日集まる場所 (インターネット回線と電源があって座れる場所) の確保

当日にチームでやった，アプリの改善以外のこと

  • 起床
  • 集合
    • 遅刻
  • 昼ごはんの調達
    • 昼ごはんを食べに行ったり買いに行ったりする暇はない
  • 物理的な開発環境の構築
    • 電源・ディスプレイ・ネットワーク接続など
  • コンテスト参加
  • お疲れさま夕食会
  • 解散

アプリについて

まず，高速化する対象の Web アプリケーションの概要を簡単に言うと， isucari という椅子売買サービスだった．ISUCON9 予選の出題者はメルカリなので，だいたいそのままありそうな感じだった． おそらく後日 ISUCON9 公式がリポジトリを公開するはず．

アプリに加えた変更(僕が認識している範囲)

  • pprof を有効にする
  • アプリケーション起動時から変更されない設定ファイル・商品のカテゴリマスタ情報をオンメモリキャッシュする
  • ページングごとの商品一覧取得の SQL がすごく JOIN される
    • この変更の説明はまだ理解していないがとても効いている
  • ユーザー情報の一部 (ID, アカウント名, 出品数?)をキャッシュ (UserSimple をキャッシュする)
  • 支払情報・発送情報の作成を非同期化
  • パスワードハッシュ処理を軽量化
    • bcrypt の繰り返し回数を減らす
    • ハッシュアルゴリズムを bcrypt から MD5 に変更 (この変更は間に合わなかった)
  • このあたりで，CPU/DB ともに余裕が出てきたのでアプリケーションに対するベンチマークのレベルを上げる
    • isucari サービスではキャンペーン開催中という設定を用いてアクセスするユーザーを増やせるという問題設定がある

感想・反省点・学び

pprof 特訓会・土曜日にやった過去問・日曜日の予選当日参加，と非常に楽しく充実した週末を過ごすことができた．チームメイトと運営に感謝．

  • Go の構文・開発体勢が不足していたので，実装力・開発力を上げる
    • GoDoc を読む力
    • Go の構文に対する理解が不足していてコンパイルエラーメッセージでググることが多々発生
  • 再起動試験でハマったので，余裕を持って再起動試験に徹する時間を作る
    • 再起動を含む追試にパスできなかった……
    • 終了 15 分前に再起動でおかしくなることに気付いて非常に焦って直したが，追試をパスしなかった
  • 過去問をやろう
  • 過去問の別言語移植フルスクラッチをやろう
  • MySQL のユーザー名は 16 文字まで
  • AlibabaCloud の日本語メッセージがところどころ難しかったり，唐突に中国語メッセージのみになったりする
    日本語訳が怪しい図
  • その他かなり多くのことを学んだはず

AWS EC2/AWS S3/goofys/Airsonic で音楽ストリーミングサーバーを作る

過去にも Subsonic や Supersonic で音楽ストリーミングサーバーを立てていたが、構成を変更したのでメモしておく．
構成を変更するに至った背景は， Raspberry Pi での運用でアプリケーションがたまに Raspberry Pi ごと止まることがあり面倒になったことである．
システム全体の構成で考えるべき要素は「ストレージ」「アプリケーション」「アプリケーションとストレージの接続」「インターネットからの到達性」であり，それぞれについて書いていく．

ストレージについて

構成変更前は，自宅にある USB 接続の HDD を使っていた．構成変更後は AWS S3 (1AZ) を使用する．
費用の関係でこの要素はできるだけオンプレミスでやりたかったが，試験的にパブリッククラウド環境に乗せることにした．

アプリケーション実行環境について

構成変更前は，自宅にある Raspberry Pi を使っていた．構成変更後は AWS EC2 (インスタンスタイプは t3.nano) を使用する．
費用の関係でこの要素もオンプレにしたかったが，今回は試験的に AWS EC2 を使う．

アプリケーション環境からストレージへの接続

構成変更前は， Raspberry Pi に USB HDD を接続するだけ，あるいは， LAN 内でファイル共有をマウントしたりしていた．構成変更後は goofys というソフトウェアを用いて AWS S3 をマウントしている．

インターネットからの到達性

構成変更前は， Dynamic DNS を使って自宅へ接続できるようにしていた．構成変更後は AWS EC2 インスタンスなのでインターネットからの到達は設定により可能にしている．
Dynamic DNS は無料で利用できるものがいくらかあるため，この要素だけが費用の関係なくどこでもいいものだと考えた．

構成の考慮点

[Storage] -- [Application] -- (internet) -- [Client] という環境で，どこからどこまでを自宅に置くか・どこからをパブリッククラウド等に置くかというところが費用に大きく関わってくるところだ．
構成変更前では [Storage] -- [Application] が自宅にあったため，費用は非常に安く抑えることができたと思う．
構成変更後では全てパブリッククラウド環境に乗っているため費用はかかると思っているが，どの程度になるか・使用感はどうなるかという点で試験的に採用した．
また、 [Storage] だけを自宅に置き，ファイル共有サービスか何かをインターネットから到達できるようにしてアプリケーションサーバーにマウントするという形もとれる．

WSL に Ubuntu 18.04 LTS を入れた

Microsoft Store で Ubuntu を検索してインストールした．
インストールの他， Ubuntu のパッケージリポジトリを日本サーバーに変更した．変更は /etc/apt/sources.list を変更する．

sudo sed -i.bak -e "s/http:\/\/archive\.ubuntu\.com/http:\/\/jp\.archive\.ubuntu\.com/g" sources.list


その後，特に必要はないけれど結局 Ubuntu 19.04 を入れた．
Ubuntu 18.04 LTS から 19.04 など LT でないバージョンへアップグレードするには， /etc/update-manager/release-upgrades を書き換えて， do-release-upgrade する．

--- /etc/update-manager/release-upgrades.bak
+++ /etc/update-manager/release-upgrades
@@ -13,4 +13,4 @@
 #           the currently-running one.  Note that if this option is used and
 #           the currently-running release is not itself an LTS release the
 #           upgrader will assume prompt was meant to be normal.
-Prompt=lts
+Prompt=normal

参考

Ubuntu 18.04のWSL上へのインストールと初期設定

upgrade - Changing prompt from lts to normal - Ask Ubuntu

技術書典 6 のサークルチェックを楽にする

まとめ

技術書典6のサークルチェックを楽にしたい．技術書典サークルチェッカー (https://seasidelab.github.io/tbf-circle/ ) というのがあった．
技術書典サークルチェッカーでつけたスターを，技術書典公式ページに反映したい．したいのでする．

内容

  1. 技術書典サークルチェッカーを使ってサークルの概要をチェックする，気に入ったサークルにスターを付ける
  2. 技術書典サークルチェッカーでスターを付けたサークル一覧データを得る
  3. 一覧を技術書典の公式ページから入力する

上記処理の 2, 3 をブラウザのコンソールで実行できるようにした．

// サークルチェッカーのページで実行する https://seasidelab.github.io/tbf-circle/
//
// サークルチェッカーでスターを付けたサークル一覧を取得
// => "{\"12345678\":\"12345678\",\"98765432\":\"98765432\"}"
localStorage.getItem("star"); // これで取得した文字列を使う

サークルチェッカーで得た文字列をコピペする．

// 技術書典6のページでログインしてから実行する https://techbookfest.org/event/tbf06/circle
//
// 処理する時に使う wait ヘルパー
let wait = function sleep(milliseconds) {  return new Promise(resolve => setTimeout(resolve, milliseconds)); }

(async function(){
  // サークルチェッカーのページで取得してきたサークル一覧を入力する(Pasteする)
  let starList = Object.keys(JSON.parse(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX));

  console.log("start");
  // 全サークルを取得
  Array.prototype.slice.call(document.getElementsByClassName("circle-list-item-link"))
  // スターリストに入れているサークルだけ取得
  .filter(circle => starList.includes(circle.getAttribute("href").split('/').slice(-1)[0]))
  // 技術書典のサークルチェックリストに入れるボタンを取得
  .map(
    circle =>
      circle
        .getElementsByClassName("circle-list-item-name")[0]
        .getElementsByTagName("button")[0])
  // 既にスターを付けてるボタンを押すと toggle されてスターが外れるので，"追加"できるサークルだけにする
  .filter(
    btn =>
      btn.getAttribute("mattooltip").includes("追加")
  )
  // スターボタンを押す
  // 一応ちょっと wait 入れる
  .forEach(btn => { btn.click(); await wait(200); });
  console.log("end")
})();

Firefox 65.0.1 で実行した．
なお， wait 入れたりしてから動作確認してないので動くか不明

リンク

techbookfest.org

https://seasidelab.github.io/tbf-circle/

振り返りには色々ある(PDCA, KPT, YWTなど)

最近知った振り返りの色々をメモする．

振り返りの手法として KPT, YWT などがある．

KPT は Keep, Problem, Try の頭文字をとったもので，それぞれ「 Keep したい良かった行為」「発生した問題」「Keep を発展・継続するために Try すること， Problem を避ける・解決するために Try すること」を書き出していく手法である．

YWT は Yatta, Wakatta, Tsugiyaru の頭文字をとったもので，それぞれ「やったこと」「わかったこと」「つぎやること」を書き出していく手法である．

 

振り返り単独の手法ではないけれど，近いものに PDCA や PDSA, PDS, PPDAC などもある．

それぞれ， PDCA は Plan-Do-Check-Act, PDSA は Plan-Do-Study-Act, PDS は Plan-Do-See, PPDAC は Problem-Plan-Do-Analysis-Conclusion の頭文字をとったものである． PPDAC だけが「まず問題があってそれを解決する」という立ち位置を明確にしているけれど，他は大体同じだと思っている．

 

これらの使い分けについて考える．

まず KPT と YWT について使い分けることを考える． YWT の方が KPT よりも使える期間の幅が広いと思う．

短期間で振り返りをする場合， Keep できることがなかったという可能性があるけれど，何もしなかったということはないので YWT の Yatta は出しやすい． (短期では YWT の方がやりやすそう)

中期間で振り返りをする場合，なにかいいことはあるべきだし多分あるだろうと思うので Keep は出せる． Yatta ことは粒度を調整するのに苦労するだろう，粒度が細かいと大量の Yatta が出てきて整理が難しくなりやすい．(中期では KPT の方がやりやすそう)

こうしてみると，短期間は YWT で中期間は KPT となるように見えるけれど，短期間の YWT をまとめつつ中期間の YWT をするということも可能であり，振り返りとして各 YWT の内容を見返していくのは思い出しも兼ねて良いと思う．一方で，短期間の KPT を見返しながら中期間の KPT をおこなうのは少し難しい，なぜなら途中の各 KPT における Problem はすでに Try によって解決されて既に Problem ではなくなっている可能性があるからだ．（過去に Yatta, Wakatta ことはいつまで経っても過去に Yatta, Wakatta ことのままだけれど，過去に Keep, Problem だったことが今でも Keep, Problem である保証はない）

そして，長期間の振り返りは， KPT でも YWT でもなく PDCA 系の行為でおこなわれるのが良いと思う．長期間の活動が「特に計画もなくとりあえずやってみるか」という Do 先行で始まることは良くないからだ．長期の活動は (解決する Problem を定めて) Plan を立て，指標を定めてから始めて， Check/Study/See/Analysis できるようにするのが良い．長期間の活動は「問題 → 目的 → 目標 → 計画 → 行動 → 解析 → 計画」という流れでおこなわれ，その部分部分で KPT や YWT が使われるという形態になるだろう．

メモメモ…．

耳栓をつけて寝る

ライブ・コンサート用耳栓を買ってみた．買ってからコンサートには行ってないのでコンサートでの効果はわからないけれど，普段遣いではエアコン・冷蔵庫・加湿器などの動作音が小さくなるくらいの効果なのでインターホンの音を聞き逃すことはないしちょうど良い．

百円のスポンジ耳栓を付けて寝るのは以前にやったけれど，サイズが合ってなかったのだろう，耳の中が圧迫されるような感覚があってやめてしまった．

今回買った耳栓はシリコン製のもので，中空構造というか隙間があるのでそこまで圧迫感がなくて長時間も向いてそう．

 

ブログに何か書く程度のことをやるのが，何か物を買った時くらいしかない．もっと活動していかねば．

Mac で定期的に TimeMachine にバックアップを取るように設定した

TimeMachine の設定を ON にしておくと毎時バックアップとるけれど，そんな頻度は必要ないし作業してないときにだけバックアップを作成してほしかった．

tmutil を使って以下のように cron 設定した

2 3 */3 * * tmutil startbackup --auto