isucon12 チーム「パカパカアルパカ」で予選突破しました #isucon

昨年と同じく前職TVer同僚の @わんこ@teraken とチーム パカパカアルパカ として isucon12 に参加してきました!
昨年、そして数年前もいつも良いところ(30-40位くらい)で本選出場できなくて悔しい思いをしてきましたが、今年はついに初本選出場出来ました!嬉しい!

スコアは 30616 でした(最高 35383)。14位でした。

isucon.net

最終構成

こんな感じ。サーバ分散ほとんどできてないのが悔やまれる…

  • App1
  • App2
    • Goアプリ / SQLite (結果的にはちょびっとだけ負荷分散されてる気がする)
  • App3
    • なにもしてない (本当はapp2と同じ構成にするつもりだったけど app2 が想定より使われなかったので却下)

なお、SQLiteMySQL化は しておりません


問題テーマ

isuportsという、isuconシステムをSaaS化し企業に提供するというマルチテナントサービスのリーダーボードの高速化をして欲しい!というテーマでした。
isuconのisucon化?


前提:チーム内での進め方について

今回、進めるにあたって事前にチームでいくつか共有したことがありました。その中で以下の2つがうまく機能したかなと思います。

  1. レギュレーションは みんなで ちゃんと読む
  2. コスパの良い改善から手を付ける

1.については、過去の経験からわりと個々に流し読みしてしまってスコアに関する重要な記載を見逃すことが多かったのが反省でした。そこで今回は画面シェアしてみんなで読み進めるということをしました。
これが結構良くて、自分が見逃してるところを「ああこういうことねー」とか言いながらみんなで補填しあって進められ、内容をほぼほぼ理解して進められたのがよかったです。

2.に関しては過去の反省も踏まえて、効果ありそうでもいきなり難易度の高いところを手を付けるのではなく 明らかに改善できて簡単にできそうところから着実に潰していく というのを意識しました。
これをしていくことによって変なところでハマらず序盤から着実にスコアアップすることができ、結果としてこの積み重ねが生きて正しくスコアアップ出来たと思います。

いきなりのやらかし

レギュレーション確認後、自分のAWSアカウントでCloudFormationのスタックを起動したのですが、なんとエラーが出てしまいます。
めちゃくちゃ焦って運営さんにも質問してしまいました…お手数をおかけしまして申し訳ありませんでした!
そして右往左往した結果ログインしているAWSアカウントが間違っていることが発覚し、メンバーのサポートによって正しいアカウントでスタックを作り直すことが出来ました。これは本当に焦りました…。ここで15分くらい潰してしまったのが悔やまれます

ちなみにこれは完全にフラグでした(実はログイン成功していなかったという 😇


メンバーロール

以下のような感じです。バランスが良い。

  • toritori0318: 全体設計したり足回りやったりアプリ周り改善したりデータストア周り改善したり
  • わんこ: アプリゴリゴリ改善してく
  • teraken: 全般で細かい部分を拾ってくれる。メンタル強

初手

みんなの考察(他にもあったかも)。

  • 外部認証は前回と似てる感じっぽい
  • 429ステータスコードはよくわからんけど一応頭に入れておく
  • とりあえずリーダーボードはRedisだよね。あと採番やキャッシュでも使えそうなので確実に使う方針で
  • アプリがdocker-composeで動いとる
  • SQLite????しかもいっぱいファイルある!どうしよ
  • MySQL側はデータ少ないけどSQLite結構いっぱいある…
  • flock?

SQLiteどうするか?問題

SQLiteなんてまともにチューニングしたこともなく本当に悩みましたが、以下の理由によりMySQLに置き換えるのは一旦やめました。

  • おそらく移行だけで相当な時間が取られる(データ移行だけじゃなく、データ整合・コード変更など影響が大きい)
  • かつ、MySQLに移したからといってパフォーマンスが上がる確信が持てなかった
    • 既にファイル分散できているし、実は使い方によっては現状の構成のほうがパフォーマンス良い可能性もある
  • SQLiteのサーバ分散対応に関してはいくつかアイデアがあったのでなんとかなるかも
  • いくつかはRedisに持たせられそう

結果MySQL移行はリスクが高く不確実性も高そうだったため、最初の方針に則りまずは コスパの良いできる改善を着実にやっていく ことにしました。


やったことまとめ

※結構口頭ベースでやり取りすることが多く、あんまりSlackに残っていなかったため間違っている部分もあるかもしれません!!また、分かりづらい文章になってしまってすみません。

序盤

自分はとりあえずいつもどおりデプロイシェル、モニタリング系のツール入れたりalias入れたり周辺準備を進めてベンチ実行。alp / pt-query-digest / SQLITE_TRACE_FILE / pprof などで状況把握しメンバーに共有。
やっぱりranking APIをなんとかしないとなーという感じ。

その後は各々以下のような対応を進めていました。

  • @teraken docker-compose剥がし
  • @toritori0318 sqliteのdistinctうんたら〜のとこにindex貼る
  • @わんこ idgen Redis化
  • @toritori0318 MySQLのGROUP BY狙いindex
  • @わんこ visit history Redis化

この辺で 6627 点くらい。

SQLite、explainとかできんのかな?とググったら普通に出来そうだったので、時間かかってそうなクエリ計画見ながらインデックス貼ったりして、普通にチューニング進められました。

中盤

429 Too Meny Error時の挙動が気になるので検証コードを@terakenに依頼。

並行して自分もきちんとアプリ見始める。やっぱflock周りがブロックしてそうだなーというところで「試しにこれ一回消してみよ」とflockしてるとこ消してみたら 普通に通った…!?
この挙動、Redis化の対応と関連してるかどうかまでわかってないのですが、とりあえず問題無さそうなのでこのまま採用。
そしてスコアも 10900 へ。

その後、player_scoreのリストからplayer引くN+1を発見したのでこれはサクッと対応。
この時点でスコア 14433 。

init時にはsqliteにindex貼ってたけど、createTenant時にはindex貼ってなかったのに気づいたのでそれを対応。
この時点でスコア 14914 。

ちなみにこの時点でRedisやMySQLは結構空いていて、ほぼ7割くらいはアプリ負荷になってました。

並行して@わんこがガリガリRedis化やバルクインサートでアプリ改善してるので、この辺りでそろそろアプリのサーバ分散考えないとなーということでインフラ構成考えてたりしていました。

閑話休題。アプリの分散・SQLite協調化についての設計

アプリ過負荷だしSQLite分散問題もあるし、どっちも同時に分散したいなー。さてどうするか。。
実はこれは「double(triple) writeでいけんじゃね?」と当初から考えてました。
そして実際POST APIのリクエスト数も少なそうだし、POST APIだけ全サーバに書き込みして、GETを分散する方法。
これは割と業務実績としてもやっていることだったし1考え方は間違ってないはず…

自分は普段からNginx / OpenRestyでかっこよく課題解決するのを生きがいとしているので 2 、Nginxでshadow proxyできるのを思い出し、これ上手く行ったらかっこいいな!と思って実際に使ったことはなかったんですが挑戦してみることにしてみました。

イメージとしては以下のような感じ(keepaliveとかヘッダーは抜いてます)。

upstream app1 {
  server 127.0.0.1:3000;
}
upstream app2 {
  server 192.168.0.12:3000;
}
upstream app3 {
  server 192.168.0.13:3000;
}

upstream app123 {
  server 192.168.0.11:3000;
  server 192.168.0.12:3000;
  server 192.168.0.13:3000;
}

server {

  # 分散対象とする get api (一部)
  location ~ ^/api/player/competition/(\w+)/ranking {
      proxy_pass http://app123;
  }
  
  # mirror対象とする post api (一部) 
  location ~ ^/api/organizer/competitions/add {
      proxy_pass http://app1;
      post_action @mirror2;
  }

  # mirror
  # 全台に反映したいので mirror3に数珠つなぎ
  location @mirror2 {
      internal;
      proxy_pass http://app2$request_uri;
      post_action @mirror3;
  }
  location @mirror3 {
      internal;
      proxy_pass http://app3$request_uri;
  }

はてさて上手くいくのでしょうか…

終盤

そうこうしているうちに @わんこ がplayerキャッシュやらbulkインサートなど対応し、スコア 30000超え!
そして自分も上記のAPI分散実装出来たつもりだったので「これで上手くいけば結構上がるはず…!」という期待を込めて適用してみた所 スコアはほぼ微増… 😇 なんで?
ログ見ると、POSTはミラーリングされてるっぽいけどGET系があんまり分散されておらず、負荷がapp1に偏ったまま。ここは未だに何故nginxのupstreamでラウンドロビン分散してくれないのかよくわかってないので感想戦で検証したい所。

またRedisやMySQLも別サーバに分散しようとした所、initializeで結構重い処理をしているため30秒に間に合わずコケる事象に。結局最終的にはサーバ分散が殆どできてない状態になってしまいました。

そしてなぜかスコアも上がることしかしてないのにだんだん下がっていき、これ以上やってもリスク高くなりそうとのことで再起動チェックすることに。

再起動チェック

残り30分くらいでサーバを1台ずつ再起動テスト。すると 理由もわからずinitializeがコケる事象 が発生し全員焦るw
結局、なぜか「ログオフを適用するとコケる」ということが発覚し急いで戻し。これなんでinitializeに影響があるのか未だにわかってない…。
そしてさらにサーバ2も再起動テストすると、docker-composeを外した新規作成サービスがdisableになっててさらに再起動テスト失敗 😱
この時点で残り10分を切っていたけど焦らずサービスをenableにしてrebootコマンド実行。問題なくデーモン起動されていることを確認。
ここは本当にヒヤヒヤした…

そして最後にベンチ実行して
30616
でFinish!


感想

とにかく楽しかった!やってる最中でもメンバーと「たのしー!」言いながらやってました。
本選も初出場なので本当に楽しみです。 しっかり準備して良い結果が残せるようにがんばります!

運営の皆様、本当にこの大規模な大会で安定したアプリ・インフラのご提供、また素晴らしい問題を作成していただきまして本当にありがとうございました!


2022/7/26追記

@わんこ 視点のブログも公開されましたのでアプリ改善の詳細はこちらをご覧くださいませ〜 techblog.tver.co.jp


おまけ

コミットログ笑った


  1. サービスの無停止データ移行得意です!(泣

  2. 誇張です

2021年の振り返りと退職と

つい先程まで行われていたTV連動企画監視を終え、それを最後1に本日が株式会社TVerの最終出社となりました。
大変お世話になりました🙇‍♂️

退職・転職について

自分は現所属において、かなり特殊な経歴を歩んで(歩まされて)きました。
何度も大きく組織が変わりゆく中で、自分の思いと経営との齟齬が大きくなったことが退職の大きな原因かなぁと思います。
そういう意味で、当初のビジョンを実現しないまま辞めてしまうのは大変無念な気持ちもあります、が、後ろを振り返っても仕方がないので
前を向いて新天地で新たなチャレンジに向かっていきます!


仕事

総評

2021/04にまたまたまた所属が変わることになりました(そして退職へ)。
様々なプロダクトがリリースできたり出来なかったりで右往左往してましたね 😇
色々な意味でとても勉強させていただきました。

家庭

とにかく子供の成長が芳しく、親としては嬉しい一年でした。
子供たちの才能を如何に伸ばしてあげるか、思案中です。

病気無し継続中

toritori0318.hatenadiary.jp

去年に引き続きまだ病気無し継続中です。丸5年の6年目!


2022年

まずは、本日より2022年2月末までの丸々2ヶ月は有給消化期間になります。
飲みの誘いがあればすぐにでも行きますのでご連絡お待ちしております〜
そして2022年3月から新天地での稼働になる予定です。やってくぞ!

それでは本年もよろしくお願いいたします!!


  1. 実はもうちょい引き継ぎが…

だいすき日本のお取り寄せが難しいのでまとめてみました

一時、悲しすぎるツイートで話題になった pradahan vikas (@daisuki_vikas) | Twitter だいすき日本 というネパール料理店があります。

そしてこのコロナ禍で再度経営に影響があり、最近お取り寄せで通販を開始したようです。
詳しくはこちらの記事をご覧ください。

rocketnews24.com

ただしこの通販、難易度が結構高いのです 😅
そこで通販の方法を詳しく解説してみたいと思いますw

お取り寄せフロー

  1. 【前提】やりとりはすべて ひらがな or カタカナ で行います
    • 例外として、名前と住所は漢字
  2. Twitterをフォローします
  3. Twitter DMで 「おとりよせしたいです!」と送信します
  4. 返事が来たらTwitter DMで以下の内容をお知らせします
    • お取り寄せしたい商品を記載します
    • ビカスさんから返信が来たら、以下の情報をこちらからDM返信します
      • 名前(漢字とひらがな)
      • 住所(漢字)
      • 電話番号
    • ビカスさんから商品送付した旨/振込先/肉まんの作り方などがDMで届きます
      • 自分のときは商品送付まで4-5日くらいかかりました。混み具合によって変わるかもしれません
    • 品物が届いたら合計金額を確認し、振込先に振り込みます
      • 実は合計金額が明記されていないのでこちらで計算して振り込むことになります。振り込む前に 合計○○円で間違いないですか?と確認しましょう!
    • 振り込みした旨をDMで返信します

以上です。
真面目に 簡単な注文フォームとか作ってあげたい…!


お取り寄せ商品

2021/1/26現在、以下の商品がお取り寄せ出来るようです。
ただし日々商品が変わっているようなので商品が追加/削除されることもあると思いますし、もしかしたら値段も変わる可能性があります。
その点はご了承くださいませ。 1
また、商品は冷凍商品となります。

  • 商品
    • カレー肉まん: 250円
    • カレーチーズ肉まん: 250円
    • キーマカレーパック: 500円
    • バターチキンカレーパック: 700円
    • マトンカレーパック: 700円
    • ほうれんそう チキンカレーパック: 700円
  • 送料
    • 着払い(都内でも1000円はかかります…)


キャンペーン

たまにキャンペーンしてるみたいです。

※2021/1/26現在では以下のキャンペーン中のようです

mobile.twitter.com


実際の商品

カレー肉まん。肉厚で具たっぷり。当然上手い

f:id:toritori0318:20210126020025j:plain
カレー肉まん

バターチキンカレー。当然上手い

f:id:toritori0318:20210126020046j:plain
バターチキンカレー


補足: 蒸し器が無い場合

自宅に蒸し器がなかったので、鍋で代用できる商品を購入しました。

サイズ別に売ってるのでご自宅の鍋に合うサイズをご購入くださいませ。



  1. 最新情報をDMのやりとりで確認したほうが良いかもしれません

整理収納アドバイザー2級を取得した話と、お部屋改善の話

f:id:toritori0318:20210104063324j:plain


整理収納アドバイザーとは

housekeeping.or.jp

要は
お部屋のお片付けにお悩みの方を解決するための理論/手段を身につけるための資格
です。
お掃除に関してはスコープ外ですのでご注意ください。

グレードとしては以下が用意されています。

  • 整理収納アドバイザー3級
  • 整理収納アドバイザー2級
  • 整理収納アドバイザー準1級
  • 整理収納アドバイザー1級

1級になると整理収納アドバイザーのお仕事として働くことが出来るそうです。
自分が取得したのは2級ですが、知識としては1級相当とのことで
あとはそれが きちんと頭に入っているか/自分の考えで実践できているか が2級とは異なるところなのでしょう。
ちなみに2級以下は基本的には受講すれば合格するとのことです(※例外がある可能性はありますが)  

また、公式テキストはAmazonでも購入可能となっています。

いままでは普通にどこかの会場に行って受講する必要がありましたが、このコロナ時代となりリモートでの受講も可能となっています。
自分もzoomで受講し取得しました。

資格に関してですが、結果的に取得して とても良かった と思っています。
片付けられない思考、片付けるための理論、実際の手法などを学ぶことができ、今後の生活にとても役立つものになりました。
ただこれは自分が元々片付け下手だったこともあるので、そうでない人にとってはあまり意味のないものかもしれません。その辺りはご了承くださいませ。

ちなみに、このブログ記事では整理収納アドバイザーの具体的な内容(要は片付けるためのコツ的なもの)は実はそれほど入っていません。
その話はまた機会があれば別記事にしてみたいと思います。


目次


資格取得の動機

ちなみに自分が何故受けたのか?についてですが
自宅の整理整頓をしたかったから
という至極当然の理由からです :)
ただ、この問題は本気で数年間悩みつづけており、いろんな思考を経て資格取得に至りました。それは後述します。

従来からのお部屋悩み

状況を整理してみました。

  • 元々、自分も家族も物を大事に取っておくタイプである。
  • 一時期、自分も家族も超絶忙しい時期が重なり片付けする暇がなくなった結果、気づいたら物が溢れていた
  • コロナで自宅作業がメインになったことにより、よりお部屋の状況が気になる
  • 少しずつメンタルに影響が出始めてきた
  • 今に至る

お部屋に関しては元々数年来の悩みとなっており幾度となく改善しようと試みましたが根本的に解決するにまでは至りませんでした。

ちなみに部屋の状況ですが、よくTVで見るような汚部屋というレベルではなく、日常的に散らかっている程度です。

もちろんそういった中でも自分も家族もお片付けはしているのですが、テーブルやソファに物が置きっぱなし・床に物が置きっぱなしという状況はなかなか改善されませんでした。
なぜなら それらを収納するスペースが無いから です。 とにもかくにも物を減らす必要がありました。

提案

なんとか現状を改善したかったため、以下のような提案を行いました(抜粋)。 1

  • 「誰が悪い」という話ではなく、家族事の問題とする
    • できるところはみんなで協力してやっていく
  • 目的
    • くつろげる部屋にする
    • 健康に良い部屋にする
      • 衛生面
      • 精神面
    • 教育に良い部屋にする
      • 現状子どもたち自身で片付けられない
        • それは子どもたちのせいではなく「片付けられる部屋になっていないから」
        • 子どもたちが自分自身で片付けられる部屋にする
    • 解決策
      • お金で解決する。上限(予算)は決めない。
      • お片付けサービス
      • 家事代行サービス
      • ランクルーム
      • オークション代行
      • おもちゃ買取
      • 本買取
    • 特にお願いしたいのが「お片付けサービス」
      • まず、最適な片付け方/家具配置がわからない
        • それらをプロから教わるのがとても大事
        • キレイな部屋を継続するためのコツを学ぶ

そして整理収納アドバイザー取得

ある時ひょんなことから整理収納アドバイザーの資格を知ることとなりました。
それを見て、自分が知識をつけて整理収納アドバイザーと同じだけのスキルを身に着けたら良いのでは?と思いました。
資格自体の金額も決して安くはないのですが、お片付けサービスのコンサルを頼んだとしても普通に 1-2万円はかかります。
それを考えたら自分で取得して今後の糧にしたほうがお得では?と思い資格取得に踏み切ってみました。


お部屋改善(進行中)

いきなり全部は出来ないので、現状は以下の方針にスコープを絞ってお部屋改善を進めています。

  • (再校)お金はいくらつかってもよい
  • まず、何はなくとも 家から物を減らす
  • 収納は買わない。物の整理が終わってから購入する。
  • 共有物/パーソナルなもの(個人所有物)含め、基本的には全部 決められたところのみ に収納するように意識する。

家から物を減らす

明らかに収納容量のキャパシティ不足なのでまずは減らさないと始まりません。
そのための手段として以下を提案しました。

  • サマリーポケットで季節外のものを預ける
  • 新規にトランクルームを契約し、処分する・しないに関わらずアクティブではないモノを一時的にトランクルームにとにかく移動する
  • できれば、メルカリやオークションなど手間・時間のかかる手段は避ける
  • 一括処分出来るサービスを利用する
    • 出張ブックオフ
    • 出張買い取りサービス
    • リサイクルショップ
  • 本はできるだけ電子化

物を処分するのはやはりそれなりに労力を使います。
しかも対象物は膨大です。まともに待っていたら数ヶ月かかるでしょう。作業者に負担を強いてしまいますし、またそれだけの時間は待っていられません。
そのためまずは対象物を ランクルームに物を移動する ことを提案しています。
同時に処分出来るものはしてもらっています。

その結果、特にここ最近は積極的に家族に協力してもらっていて劇的に改善が進んでいると実感しています。
本当に有り難いです。


家族をどう説得するか

実はこれが一番難しいところです。
一人暮らしであれば片付けたければ自分で自分のものを整理すれば良いのですが家族で暮らしているとそうはいきません。
そして、片付けに対する温度感も確実に異なりますし無理やり進めても必ず衝突することでしょう。

身も蓋もない話ですが、これについては やり方に正解はない と思っています。
部屋が心地良いかどうかは同居人により異なりますし、それをお互いに共有しディスカッションする必要があります。
そもそも「なんのために整理整頓を行うか」を認識/共有し、それをお互いに共有することが重要になってきます。
ただ、一つ確実に言えることは
その家に住んでいる家族全員がハッピーに暮らせる部屋になっているかどうか
が焦点となるでしょう。

前提

本題に入る前に、まず大前提として 感謝の心を忘れない ようにしましょう。
整理整頓を進めるにあたって提案している方はもちろん目的があってのことですが、
言われている方はなかなかモチベーション維持が難しいところです。
なにか一つ達成したら必ず感謝を忘れずに。

もう一つは絶対に否定したり批難しないこと。
物を所有すること自体は決して悪いことではないからです。
相手の意見も尊重しながら落としどころを見つけていきましょう。

説得方法

以下のような方法が考えられるかと思います。おすすめ順にソートされています 2

  1. 整理整頓することによって起こる良いことを共有する
  2. 理論で説明する
  3. インセンティブを与える
  4. 整理整頓しないことによって起こるネガティブなことを共有する

1. 整理整頓することによって起こる良いことを共有する

やはり基本的には整理整頓でポジティブなことが起こるよ、というのを伝えるのが良いと思います。
ざっくり言うと 家族にとって暮らしやすい部屋にしたい と提案する感じでしょうか。
そして どういう部屋にしたいか といった目的もセットで共有するのが良いでしょう。

以下、一例です。

  • 子供が自分で片付けられるレイアウトになる
  • ルンバがきちんと掃除してくれるくらいの部屋にする
  • 所有物をきれいにディスプレイしたい
  • エアロバイクを置くスペースを確保したい
  • 片付いたことにより
    • 健康的になる
    • ものを無くすことが確実に減る/ものを探す時間が減る
      • 結果、イライラが減り、時間に余裕もできる

2. 理論で説明する

整理収納アドバイザーでもポイントとして上げられていたのですが、
まず 自宅の収納の適正量を知る ことがとても大事です。

例えば、理想とする家の容量を 100 と仮定してみましょう。
そして容量100の場所に容量200のモノ詰め込んだらそれは生活するのに不自由な部屋と言わざるを得ません。
それがみんなが利用する共有スペースならなおさらです。
その状態で何も考えず物を増やすことはいわば
コップの水を溢れさせたままさらに水を注ぐ(新しいモノを増やす)
ようなものです。
その辺りを理解してもらいお互いの認識を合わせるのが良いかもしれません。

例として、自分の考える100という単位は以下を満たしていることです。 3

  • テーブルの上に余計なものが置かれていないこと
  • 床に一切物が置かれてないこと
  • 収納となる場所がすべて 定常的に利用できる状態になっている こと(物置状態になっていない)
    • ※例外として「物置収納と定義した場所」は除きます
  • 収納は 8-9割 で納めること(クローゼットがぎゅうぎゅう詰めにならない/本の上に本を横に置かない、など)

注釈にも書いていますが、この値は同じ100だとしても 家庭によって基準値が異なる ことにご注意ください。
相談して、明示化することが大事です。
かつ、家庭によっては「100のところに120までなら許容しても良いよ」という意見も考えられます。
硬く考えずに柔軟に考えましょう。

3. インセンティブを与える

あまりやりすぎも良くないですが ご褒美 を用意するのも一つの手かと思います。
ある程度の閾値を定義して ここまでやったら何かを与える という手法です。
もし、対象者が欲しい物があるのであればチャンスかも知れません。
あるいは「片付いたらそのスペースに欲しがってたあれ買ってあげようか?」といったアプローチだとより良いかもしれませんね :)

4. 整理整頓しないことによって起こるネガティブなことを共有する

悪手にはなりますが、上記でも同意を得られない/またはなかなか状況が改善されない場合は
最終兵器としてネガティブなことを伝えるのも手かもしれません。

  • そもそもこういうことを話したり議論すること自体がネガティブ
    • お互いに精神的苦痛がある
    • プレゼン/議論する時間が無駄
  • 雑然としすぎていて家にいるのがストレス
  • 子供の教育に良くない

まとめ

  • 整理収納アドバイザーは、整理下手な人が手法を学ぶには最適
  • 実際自分が抱えている自宅の悩み/解決方法
  • まだ絶賛進行中ではあるが、家族の協力もあって改善されてきている
  • 個人ではなく家族事とし、みんなで話し合って解決する
  • 同居人にはなるべくモチベーションを持って整理を進めてもらえるように工夫する

もちろん、ものを大事にしたりたくさん欲しい物を所有することは良いことだと思いますし尊重したいです。むしろ家族としては好きなものを好きなだけ購入して楽しく暮らして欲しいです。
ただ、それが家族の限度を超えている場合には話し合いましょう。
物の取り扱いについて折り合いをつけて、家族として幸せになるところを見つけていくのが大事だと思います。

Ref: 参考サイト

※注意 参考サイトで発生した事象につきましては一切責任を負いませんので自己責任でお願い致します。


  1. 誇張ではなく、今年は本当にプライベートの半分くらいは片付けの事調べたり、家族へのプレゼン資料作ったり、お片付け計画を立てたりしていました

  2. 他にもあれば是非教えて下さい!

  3. この100という単位は家や人によって異なります

2020年振り返り


今年は例年とは異なるスタンスで過ごした年だったように感じます。

もちろんコロナの影響もあるとは思いますが、なんというか一歩引いた目線で改めて自分自身を見つめることが多かった年かもしれません。

仕事ももちろんそうですし、プライベートもそう。

そしてそれを文面にしてみるとわりとポジティブにも見えますが、むしろ悩んだり迷ったりすることが多く、自分に投資するどころではありませんでした。

とはいえ、まあそういう時期なんだろうと達観する自分もいて、そういう意味では少しは成長したのかも?しれません :)

仕事

総評

またまた勝手に所属が変わり、会社としての状況も今までより大きく変わりはじめています。
プロダクトに関してはとてもポジティブなのですが、その反面自分のキャリアについてはうんうん悩むことが多かったですね。

他には、なぜか立て続けにいろんな方面からお声がけいただくことがあって
今までやってきたことは間違いではなかったんだな、と再認識することができました。
ありがたいことです。

家庭

別記事でも書きましたが(※先に書く予定だったのですが、間に合わなかったのであとで書きます!)、とにかくお部屋改善に注力した一年でした。
まだまだ途中ですが諦めず継続してやっていく所存でございます。これ実はメンタルに影響しているので何よりも最優先で。。

コロナにより家族と過ごすことも格段に増えました。家事も割と手伝えていると思ってます。
子どもたちは相変わらず仲良しに、そして自由奔放に日々過ごしているようです。

奥さんとも話してはいるんですが、本当突き放すところは突き放さないといけない時期だと思うので
子どもたちのためにも甘やかしすぎずやっていきたいですね。

病気無し継続中

toritori0318.hatenadiary.jp

去年に引き続きまだ病気無し継続中です。丸4年の5年目!


2021年

上記でも書きましたが、仕事よりもまずはお部屋改善を優先してやっていく予定です。
次に仕事。来年の計画ももう1年くらい先までロードマップが引かれているので引き続き頑張る所存でございます。どうなることやら。。

というわけで来年もよろしくお願いいたします!!

WFHポエム

緊急事態宣言から1ヶ月以上経ち、リモートワークベースの会社も増えてきたことと思います。
それに伴い各社様々な施策を打ち出してきていますね。

最近リモートワーク推奨意見をちらほら目にしていて思うところがあったので記事にしてみます。

※前提

以下すべて コロナが収束した後の話 として書いております。



現状 > コロナ収束後

現状は状況的にWFHせざるを得ない状況下にあると言えます。
ただし、仮に 完全にコロナが収束したとしても 今までとは大きく変化した世界となっていることでしょう。
それはもちろん働く環境も例外ではありません。
週5で出社する会社なんて珍しくなっているかも知れませんね。


リモートワークどうなの?

ところでリモートワークですが、おそらく 意外と普通に仕事できてるじゃん という感想の方が多い印象です。
それはやはりリモートワークにおけるツールやサービスが充実していることに尽きるでしょう。
仕事上のコミュニケーションに関しては大きな不便はないと考えています。

とはいえ、やはりWFHにおけるメリット/デメリットはあると思っています。
よく言われるところとしては以下のような感じでしょうか。

  • メリット
    • 通勤する必要がない
    • 誰もいないので集中できる
    • 服を気にしなくて良い/お化粧しなくても良い
    • 荷物を受け取ったり病院に行きやすかったり用事を済ませやすい
  • デメリット
    • なんだかんだコミュニケーションロスがある
    • ビデオ会議でブツブツ切れる
    • 微妙なラグで発言しづらい
    • 他の人の話が聞こえないので何やっているかわからない
    • おしゃれなオフィスが好きだったのに…
    • ランチの選択肢が少ない
    • 一人で寂しい気持ちになる
    • 仕事する部屋がなくて集中できない
    • 子供/奥さんがちょいちょい話しかけてきて集中できない
    • そもそも幼児がいるので世話で仕事にならない
    • みんなで飲みに行けない
    • みんなで飲みに行けない
    • みんなで飲みに行けない

やはり一番のメリットは通勤する必要がないことですね。
ただし次のトピックにもなるのですが、必ずしもメリットが全員に関してメリットとは言えない場合もあります。

リモートワークにおける不平等

リモートワークするということは社員が 各々の環境で仕事する ということです。
その時点で不平等が発生しています。

例えば、ある社員は「一人なので仕事に集中しやすい」という意見でしたが、家族持ちの社員は「子供に邪魔されて仕事に集中しづらい 1 」、また一人であっても「普段リラックスする場所なので逆に家だと集中できない」といった意見もあるかも知れません。

また金銭的にも不平等が発生します。 よくある話としては通信費もそうですし、普段家に誰もいないのでWFHだと電気代がかなり高くなる人 2 など出てきそうです。 もちろん手当支給などでまかなう方法もありますがメンバーごとに異なる環境にどの様に対応するか?は今後の課題になるでしょう。 3

特に大きな会社であればあるほどこの不平等感に不満を持つメンバーが多く出てきそうな気がしています。

そういう意味でオフィスというのはある程度平等に各メンバーに働ける環境を提供できていたのではないでしょうか? 4


で、どうしたらいいの?

これは超個人的な意見ですが

  • 基本的に出社/リモート作業の選択は社員の自由
  • ただし週1(or 月1)は全員出社する日を決めておく

くらいが理想かなと思います。
どうしたってWFHが合っているかどうかは社員毎に異なりますし、基本的には社員毎に選択させる方式で。
顔を突き合わせて話したいことはやっぱりあるので最低限月1くらい(自分は週1でも)は機会がほしいですね。


余談:シェアオフィスの需要

コロナ収束後も社会全体的に出社機会が減る方向に進むと考えられるので、実はシェアオフィス需要がとても上がるのでは?と想像しています。
固定のオフィス契約ではなく席を縮小したシェアオフィスで契約し、メンバーが集まる日は会議室で会議したり、共有スペースで席を補填したりする形態ですね。
割とあるのではないでしょうか?


余談:弊社YourCastの場合

まず、緊急事態宣言が出る前のかなり早い段階から リモートワーク備品購入補助5万円支給(何にでも利用可能) がありました。

また今月から通勤手当も廃止し、毎月リモート補助金1万円支給 することになっています。
このように、弊社は経営がメンバーのことを考えてめちゃめちゃ迅速に対応してくれるのでとても助かっています! 手当に関してもおそらく状況に応じて改善してくれることでしょう。

エンジニア絶賛募集中ですので、もしご興味のある方は Wantedly or Twitterでご連絡ください〜


まとめ

コロナ収束後、出社するにしてもフルリモートするにしてもまず
「社員自身がパフォーマンスを出せる環境かどうか」
「会社のプロダクト/チームとしてパフォーマンスを出せる環境かどうか」
に尽きると思っています。
会社の事業/グローバル制/文化にもよると思うので、会社によって最適解は異なるでしょう。
その時、どちらにしても 会社がフレキシブルに対応してくれるかどうか に尽きます。
仕事する環境というのは本当に重要です。
一社員として妥協せず会社と議論していきましょう。

では最後に、自分の意見を引用して終わります。


  1. 学校が始まったとしてもお昼過ぎには帰ってきますしね…

  2. 特にこれから夏場を迎えるにあたってかなり金額に違いが出てきそう

  3. ※これは特殊例ですが、某同僚は喫煙しながら仕事ができるようになったので煙草代だけで手当が無くなってしまう、と嘆いていました 😇

  4. 定期代は社員毎に異なりますが、普通に通勤手当として請求になるのでかかるコストとしては平等です

Redis 6.x の Threaded I/O 対応雑感

2020/5/6 追記

  • ベンチマーク結果に mset / sadd / zadd / hset / lpush / lrange 300 を追加しました


Redis 6系がリリースされましたね!
mag.osdn.jp

やはり気になったのは「マルチスレッド対応」という文字。
Redisといえばシングルスレッドでしたが、今回の対応がどういうものか?パフォーマンスにどの程度影響するのか?が気になったので軽く調べてみました。


redis.confの説明文

redis.confTHREADED I/O の頁が追加されています。
要約するとあくまで I/Oアクセスをマルチスレッド化 する対応のようです。 1


スレッド化なし/あり時の実際のプロセスの様子

io-threads=1の時
f:id:toritori0318:20200506025518p:plain

io-threads>1の時
スレッド表示OFF f:id:toritori0318:20200506025523p:plain スレッド表示ON f:id:toritori0318:20200506025601p:plain

きちんとスレッド化されている様子がわかりますね!


ベンチマーク

簡易的なベンチマークを取ってみました。

環境

ロール OS インスタンスタイプ Redisバージョン
Redisサーバ AmazonLinux2 c5.2xlarge(8core) Redis 6.0.1
ベンチマーククライアント AmazonLinux2 c5.2xlarge(8core) Redis 6.0.1

OSチューニングしたところは ulimit / net.core.somaxconn くらいです。

ベンチマークコマンド

スレッド数8、パイプライン16並列でループ実行しました。

# get/set
redis-benchmark -t get,set -n 1000000 --threads 8 -P 16 --dbnum 1 -q -l

# mset
redis-benchmark -t mset -n 1000000 --threads 8 -P 16 --dbnum 1 -q -l

# sadd
redis-benchmark -t sadd -n 1000000 --threads 8 -P 16 --dbnum 1 -q -l

# zadd
redis-benchmark --threads 8 --dbnum 1 -q -l -n 1000000 --threads 8 -P 16 -r 1000000 zadd myzset __rand_int__ member:__rand_int__

# hset
redis-benchmark --threads 8 --dbnum 1 -q -l -n 1000000 --threads 8 -P 16 -r 1000000 hset myhash field:__rand_int__ value:__rand_int__

# lpush
redis-benchmark --threads 8 --dbnum 1 -q -l -n 1000000 --threads 8 -P 16 -r 1000000 lpush mylist __rand_int__

# lrange_300
redis-benchmark -t lrange_300 -n 1000000 --threads 8 -P 16 --dbnum 1 -q -l

サーバ起動コマンド

io-threadsの数値を変えて比較してみました。 2

redis-server --protected-mode no --io-threads <num>

結果

ループで10回程度回したrps平均値です。

Redisサーバスレッド数 get set mset sadd zadd hset lpush lrange_300
1 1,155,995 1,344,768 347,639 1,283,881 259,651 799,513 1,036,402 53,091
2 1,196,952 1,415,721 351,426 1,337,262 261,772 837,762 1,100,286 53,603
4 1,232,383 1,500,202 355,968 1,397,251 267,699 853,392 1,130,196 53,930
6 985,922 1,227,587 193,678 1,277,302 239,738 618,960 1,085,098 27,358

4スレッドくらいまでは順調にパフォーマンス上がっていますが、6スレッドでは逆に性能劣化していますね。。
スレッドの増やし過ぎもよく無さそうです。

redis.confの説明では

By default threading is disabled, we suggest enabling it only in machines that have at least 4 or more cores, leaving at least one spare core.  
Using more than 8 threads is unlikely to help much. 
We also recommend using threaded I/O only if you actually have performance problems, 
with Redis instances being able to use a quite big percentage of CPU time, otherwise there is no point in using this feature.

とありますので、よく考えて設定する必要がありそうです。


まとめ

スレッド化することによりパフォーマンスの向上がみられました。
ただし単純に増やせば良いものでも無さそうなので、実際にスレッドI/Oを利用するときにはきちんと性能評価を行った方が良いでしょう。



  1. つまり計算量過多による挙動は変わりません。試しにスレッドを有効にして大量の keys * 実行後に他オペレーションがブロックされるかどうか確認してみましたが、やはり今まで通りブロックされました。

  2. ちなみに redis.confの io-threads の値を変えて試してみたんですが実際に反映しないような気が…?