isucon13 チーム「パカパカアルパカ」で22位入賞しました #isucon

isucon13、去年に引き続きチーム「パカパカアルパカ」として出場しました！

結果は score: 86322 で22位でした！

isucon.net

今年は個人的な準備があまり出来てなかったので去年より自信は無かったのですが そう考えると健闘出来たのかなと思います。


テーマ

ISUPipeというLIVE配信アプリケーション！
コメントにリアクションに投げ銭など、過去実際にサービスとして実装したことのあるようなアプリケーションだったのでテンション上がりました💪

自分のやってたこと

速攻でCloudFormation投入しつつマニュアル読み。
DNS水責め攻撃…！！PowerDNSもどういうものかは知ってましたが実際に利用したことはないのでひどく狼狽してました 😫

まずは自分担当としていつもどおりモニタリング系とデプロイシェル準備。サーバ間通信できるようにssh疎通確認したり、/etc/hosts書いたりしてました。
アプリはアイコン周りはいの一番にどうにかしたほうが良いよね、というのとstatisticsは大変そうだけどやらんとな〜、みたいな見解。

あとはいつも通り実際にベンチ回してログ見ながら重そうなとこをひたすらやってく。
他の２名はアプリRedis化やPowerDNS周りの改善などをひたすらこなしていました。

前半〜お昼すぎまで

以下は自分の作業分。

  • livestream tags indexにindex追加
  • nginxで静的配信するための設定検証
  • プリペアドステートメントOFF
  • タグ取得のN+1回避

この辺でベンチマーカーが使えなくなったりしてたので、その間にmysqlやredisを全台から疎通する準備してたり、複数台に対してデプロイするスクリプト書いたり、最終的な全体構成どうするかみたいな相談しつつそのための準備などしてました。

DNS周りは下手にいじるとハマりそうだったのと、他の機能と切り分けたほうがきれいに分散できそうかなというとこで以下の構成で行くことにしました

  • APP1: エントリポイント / Nginx / Go App (register / icon) / MySQL(DNS)
  • APP2: MySQL(アプリケーション)
  • APP3: Go App (register / icon 以外全部) / Redis

最終構成のイメージ以下のような感じ

中盤以降

分散周りの設定を進めながら、ALPとpt-query-digestの結果を回して実直にボトルネック潰していくといい感じにスピードアップしていきました！
こうなると楽しくなってくるやつですね 😁

  • livestream_tagsにindexもう一つ追加
  • livecommentsのカバーリングindex追加
  • db idle connection増加
  • reactionsにindex追加
  • reservation_slotsにindex追加
  • livestreamsにindex追加
  • MySQLパラメータチューニング

終盤、わんこ氏がstatistics周りの改善で60000超え！
その後、何故か静的画像化したselect icon がスローログの上位に戻ってきたのでなんでー？って相談してたら
そもそも取得する必要ないやんってなって改善したら80000超え！！

このあたりで17:00過ぎてたのであとはログ消しとか再起動チェックとかリスクなさそうなNginxチューニングとかしてたらおおよそ30分前…
ジョブキューのWaitingもあったのであまりチャレンジ出来ないなーと思いながらベンチ実行していくと、何故か実行するたびにスコアが下がっていくという状況に 😇
最終的に、10分前に86000台にもどしてFinish！
お疲れ様でした！！！


雑感

振り返ってみると今回は９割くらいインフラとMySQL見てた感じでした。
ただ、その辺りでハマることなくすんなり複数台構成できたり、デプロイ周りも他２人に意識させずにいい感じに提供できてたので、そこはわりと価値出せたかなと思います。

反省点としては、アプリ見直してみるとまだまだ手を付けられそうなところはありそうだったので
やはりもっと全体的にスピードを上げねばな〜という感じですね。
順位、いつもいいポジションには付けているのでもっと精度を上げてここを天元突破したい…！


まとめ

毎年多数のチーム・人数を捌く運営の方々には本当に頭が下がります🙇‍♂
今年も本当に楽しかったです！良問ありがとうございました！！


おまけ

スコア推移見れるようになってたのでスクショ貼っておきます。 お昼すぎまでは辛い時間だった様子

https://cdn-ak.f.st-hatena.com/images/fotolife/t/toritori0318/20231127/20231127210207_original.png

数年ぶりにAWS便利ツールのYogafire0.11をリリースしました

本当に久しぶりにYogafireをリリースしていました。

github.com

https://cdn-ak.f.st-hatena.com/images/fotolife/t/toritori0318/20230226/20230226223627_original.gif

※イメージで使ってるEC2やACCESSキーは削除済み


Yogafireについて

AWSを便利に利用するツールです。主にEC2周りのツールなので、最近の利用頻度としては多くないかもしれないですね。
古いですが、詳しくは以下の記事が参考になると思います。

今回のリリースについて

最近のEC2の認証の主流としてACCESS_KEYを利用しない方向になっています。
また直接のsshではなく、ssmを経由したログインも推奨されています。
そういった昨今のニーズに答えるためYogafireをアップデートしました（遅

ChangeLog

主には以下の機能をリリースしています。

  • AWS_CONFIGを直接利用出来るようにしました(.yoga ファイルは必須ではなくなりました)
  • ssm-start / ssm-start-tmux コマンドを追加しました。これにより、鍵管理すること無くssm経由でのサーバログインが可能になっています。
  • 実行環境用のDocker Imageを用意しました。これにより、ローカルのperl環境を準備すること無く利用することが可能になっています。

コードについて

Any::Mooseの警告が出ちゃうのはすみません…書き換える気力が…
というか本当Goで書き直したい気持ち。

最後に

初回リリース日、もう11年前という事実に愕然。
それだけ長年利用されているツールというのも嬉しい限りですね。
少なくなってきているとはいえ、まだまだEC2管理のサーバが生きている環境はあると思います。
もしそのような方がいらっしゃいましたら一度ご検討してみてください。

またアップデートあればお知らせいたします！

2022年振り返り

紅白を見ながらこの記事を書いています。
年末年始、完全に仕事無いの本当に10年ぶりくらいなので逆に落ち着かないですね😇


仕事

周辺状況

今年3月から株式会社StoreHeroにてCTOとして入社していました。
主な役割としては 「0 > 1 フェーズのコマースグロースプロダクトをリリースすること」 です。
入社とほぼ同時に始まったプロダクト開発ですが、予定通り2022/10にα版が無事リリースされました。今はリリース後のフィードバックを反映し、本当に価値のあるサービスを生み出すべくひたすらトライアンドエラーしまくっています。

「課題がたくさんある中で、それをどうやって技術的に解決するか」 という、エンジニアとしてやりがいしかない環境の中にいて楽しすぎる反面、事業に貢献できるサービスにするというミッションを達成しなければならないというプレッシャーも大きいです。
自分としても事実としてもまだまだ結果が出ていない状況です。来年は確実に結果を出して、関わる人達全員をグロースさせるサービスを提供します！ 💪

やってたこと

最初は「CTOって何やる人？」状態でしたが、事業に貢献するために必要なことは何なのか？をベースに考えた結果、大小はありますがいろいろな領域をやっていました。

自分の中で 「良いものを生み出すには良いチーム」 が必要と考えていたので、最初にそれを意識して進めていました。
結果、チーム開発としての生産性も良いものになったかなと感じています。
また、前職に引き続き「週１回のわいわい雑談会」も毎週行っており、チームとしての技術勉強の場やコミュニケーションに貢献出来ていると思っています。

ISUCON

今年は念願の本選出場を果たしました！ 🎉
レポートは以下をご覧ください。

toritori0318.hatenadiary.jp

toritori0318.hatenadiary.jp

少し話がズレます。
実はここ数年間、経験を食いつぶして生きながらえており技術的なチャレンジもあまりできておらずモチベーションも上がらず、以前は好きでやっていた仕事が辛い時期が続いていました。1
割と本気で「このままエンジニアとしてやっていくの厳しいかな…」とも考える時期もありました。

しかし今回の結果を得て「まだまだ自分はやれるじゃん！💪」という自信になりましたし、昔のようにもっと技術を突き詰めたい！というモチベーションも復活してきました。
いつまで続くかわかりませんが、この復活した気持ちを大事にして引き続き楽しくエンジニアをやっていく所存です！

家庭

息子も中学生になり、一気に大人になった感じがします（背も抜かれたし…）
子供ふたりとも色んなことに興味を持ち始め、好きなことに邁進しています。
子供たちが良い方向に進むように引き続きサポートしていきたいと思っています。

病気無し継続終了

数年続いていた病気なし継続ですが、今年初旬にコロナにかかってしまいました 😢
症状はそれほどでもなかったのですが、家族を含めて周りに迷惑をかけてしまったのがメンタルに来てましたね…
年齢のこともあるので今まで以上に健康には気をつけて過ごそうと思います。


2023年

上記でも書きましたが「プロダクトで確実に結果を出す」のやっていきたいと思います。やるぞ！！！！💪

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

  1. これは前職の問題ではなく、自分自身のキャリアと組織から期待されていたことの乖離によるものです↩

isucon12 チーム「パカパカアルパカ」で本戦Failしてきました #isucon

※レポート遅すぎてすみません！

isucon12、チーム「パカパカアルパカ」として初本戦に出場しFailで終了してきました！残念！

チームメンバーのブログもありますので是非ご参照くださいませ。 techblog.tver.co.jp


テーマ

ISU CONQUESTというソシャゲアプリケーションのチューニングでした。 すでに公式から 解説記事が出ているのでそちらを見ていただいくとわかりやすいと思います。

開始早々サーバが５台あることが判明し、これは分散がキーになりそうだな？という想像がつきました。1

自分のやったこと

序盤はいつもどおり足回り系と、モニタリング系の準備。
また予選では複数デプロイスクリプトがいまいちだったので、それも今回事前に用意しておいてシュッと複数サーバにデプロイ出来るようにしておいたのは良いポイントでした。
あとalpのregex集計が便利すぎて「alp便利〜」とずっと言ってましたｗ

あとはログ見ながらひたすらチューニングしまくり。

  • user_present_all_received_historyにindex追加
  • user_presentsにindex追加
  • interpolateParams設定
  • DBコネクションプーリング
  • user_one_time_tokensにindex追加
  • checkViewerIDしてるとこ削除
  • versionをオンメモリキャッシュ＋サーバ間同期取るように( これがバグってた ><
  • login_bonus_reward_masters にindex追加
  • gachaをオンメモリキャッシュ＋サーバ間同期取るように
  • initを並列処理化
  • nginx / mysqlチューニング
  • redis / mysqlを別サーバに

中盤〜終盤にかけてDBをどう分散するかの検討について

中盤過ぎた辺りからDBどうにかせんとな〜と思って「ユーザIDなら水平分散できるのでは？」と考えました。
実際に数値IDからシャーディングする実装もしたこともあるし、そんなに工数かけずに行けるやろ！と踏んでました。
しかし、とあるクエリを確認したところ「IN句でユーザID使ってるみたいだから厳しいか…」と諦めてしまいました。
ただこれ競技終了後に指摘されてよくよく見てみたらこれが完全に勘違いで、普通に分散できることが発覚 😇
こういうところも含めてisuconですね…！

Failしてないときの最終スコア

10万弱くらいだった気がします。
Failしなかったとしても入賞まで程遠いのでもっと精進します！！


延長線

運営様のご厚意で１週間ほど延長線出来ることになり、メンバーで時間のある時にちょいちょい延長線してました 2

以下自分が追加でやってたことです。

  • MySQL REDO off
  • redisサーバの場所を調整
  • select * やめ
  • 複数selectおまとめしたり
  • user_device作らない
  • sync.onceで無駄処理しないように
  • redisをpipelineで並列化
  • インフラ・ミドルウェアチューニング諸々
  • N+1潰し
  • item_type毎におまとめして処理するように

そして延長線の最終チーム結果としてはこんな感じでございました。

score: 423541

お疲れさまでした！


次回に向けて

今回Failだったのは残念ですが、自分はそれよりも入賞に届くまでのスコアが出せなかった方が悔しいです…！
やはり予選と本戦では求める水準が違うので、もっともっと素早く的確にチューニングする力が足りなかったなと言うのが正直な感想です。
スコアが伸び悩むと余裕ができず、今回のようなバグの箇所やIN句の勘違いなどミスも出やすくなります。もっと精度を上げることにより気持ちにも余裕ができより正確にチューニングができるはずです。

ただ、今回の予選・本戦の結果で僕らも少し自信をつけることができました。3
来年は是非ともまた予選突破し、次は本戦入賞を目指してこの一年で力をつけていこうと思います！

ISUCON運営の皆様・関わってくださった皆様、楽しい時間を本当にありがとうございました！

  1. 結果、もっともっと早くやっておくべきだったのですが↩

  2. この間、他の人のブログなども見ないようにしてました↩

  3. この辺りの気持ちに関しては個人的に思うところがあるのですがそれはまた別途…↩

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

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

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

isucon.net

最終構成

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

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

なお、SQLiteのMySQL化は しておりません


問題テーマ

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


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

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

  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分くらいでサーバを１台ずつ再起動テスト。すると 理由もわからずinitializeがコケる事象 が発生し全員焦るｗ
結局、なぜか「ログオフを適用するとコケる」ということが発覚し急いで戻し。これなんで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

去年に引き続きまだ病気無し継続中です。丸５年の６年目！


2022年

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

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

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

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

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

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

rocketnews24.com

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

お取り寄せフロー

  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のやりとりで確認したほうが良いかもしれません↩