eye catch

2021年2月のふりかえりです。

  • B 社で開発業務(週5日)
  • (終了) D 社で採用支援業務
  • (終了) K 社で技術顧問業務

年が明けてから B 社へ集中するために他案件の調整をしにいっており、2 月いっぱいで D 社 / K 社は終了することになりました。 しばらく B 社一本でやっていくことにしています。

B 社は春に物日がある事業のため、そこに全力で望まないと厳しいというのが発端ですが、 経年や技術マネジメント不足からくる技術負債の蓄積による技術面の難易度の高さだったり、 ここまで構築してきている業務とシステムの境界面の難しさなども相まって非常に学びが多いというのも理由になっています。 端的に言うと程よく難しい問題を延々と解き続けることができる環境ということで暇にならないのがいいところという感じでしょうか。

というわけで引き続きで B 社は Rails 製の EC サイトの開発業務と Engineering Manager / Scrum Master 業務です。

2 月は主に春の物日むけの高速化対応をやっていました。

  • EC 高速化とキャパプラ
    • apache / passenger のプロセス数の調整と EC2 インスタンスの調整
      • 物日に向けて調整開始
      • 全然キャパプラできていなかったので全体的に見直し
      • 2月下旬にマーケ施策で突発的かつ急激な流入増というイベントがあったのですが、見直した状態でも耐えられなかった(泣)ので想定プランを再度見直しました。
        • 3 月中に春の物日向けのインスタンスへの入れ替えとキャパプラ結果に修正しきる想定で動き始めています
    • RDS 周りの調整
      • Multi => Single AZ
      • インスタンスアップ
      • IOPS は昨年比較で 4 倍まで上げました、3 月中に昨年比 5 倍まで上げる計画でおり、この状態で春の物日を超えられる想定です。
    • ElastiCache(Redis) 周りの調整
      • インスタンスアップ
    • Saving Plans を適用開始
    • 重いページを軽くしていく対応
      • キャッシュに乗せたり
      • クエリ見直したり
      • PV を計測して後で集計してランキング作ったりする処理はよくウェブサイト作ってるとあると思うんですが、これを MySQL で実装していてサチってることがよくあるので作り直すなど
        • 現状チームの能力的に、迷いましたが、マネージドに寄せずに古典的な Redis ベースな設計で実装し直してます
  • 物日に向けての delayed_job プロセス数増量
    • やってみると MySQL の Deadlock が顕著になり… 並列数増やして物日を乗り越えるプランは見直すことに
    • 非同期用の EC2 だけでなく、アプリケーションサーバー用の EC2 でも delayed_job が動いていたのをやめたりもしました
      • 非同期用 EC2 にまとめてみると、今度はちょいちょい delayed_job プロセスが死亡して戻ってこない仕組みになってることが判明したので delayed_job monitor を設定しました
    • そして本丸の sidekiq への移行を開始しはじめました
      • こちらは monit を supervisor として入れています
      • Amazon Linux 1 で動いているので supervisor どれにすべきなのか？というので若干混乱しました…
        • ちなみに春の物日を乗り越えたら ECS + Fargate にする想定なので、Amazon Linux 2 にするという択は選択していないのです
      • sidekiq のモニタリングは Datadog 標準のものと、自作の Queue 情報を取得するスクリプトを 1 min 毎バッチで動かす感じでざっくりな実装にしておきました
        • こちらも ECS + Fargate に載せ替えるときにちゃんと解像度上げる対応をする予定です
    • 結果としては、期待通りで sidekiq に載せ替えた分 delayed_job の負荷は下がっているのと delayed_jobs テーブルの刺さり具合がマイルドになっている状況を作れました
      • あとは全部載せ替えるだけなので一安心です
  • 重いバッチ群が終わらない問題
    • というのが発生するようになってきており、特にレポートバッチとよんでいるものと、注文確定バッチとよんでいるものが終了まで長時間に渡ってしまい業務に支障がでるようになっていました
    • これらは僕が対応したわけではないのですが、基本的な方向性としてはちゃんと並列化するのと activerecord-import をちゃんと高速な実装にするのを真面目にやって高速化完了しています。
      • バッチ用の EC2 インスタンスのインスタンスアップも実施済みで、実行結果に余裕があることから山は超えたかなと。一安心です。
    • 上記までとは別観点で、数分おきに実行されるような小さいバッチを Datadog で観察していたところ「もしかして突き抜けているのでは？」という疑惑が出てきたので対処をいれました
      • Production リリース後、観察しているとやっぱり突き抜けていました(笑)
      • 今のうちに気づけてよかった
  • Redash が無理っぽくなってきました
    • AWS DataPipeline で置き換えること可能か？の検証したものの、AWS のやる気のなさを感じてやめました
    • しばらくはインスタンスアップしてしのごうと思っています
    • 本質的には Redash でやるべきじゃないことを Redash でやっていたり、データ関連の業務がちゃんと構築できていないというところの課題なので、こちらも物日以降に整える予定です。
  • Datadog のプラン見直しを行いました
    • App Analytics がめちゃくちゃ高かったのですが、Redis の Analytics 量を調整してかなり安くすることができました
  • 2月に入ってからクローラーのアクセスがめちゃくちゃ増えており、その負荷が無視できない様相になってきました
    • 3 月以降に、最もアクセス過多になっている Bing Bot を調整する予定です
  • アラート発生時に Slack 通知する仕組みがすでにあるのですが、Slack だけだと営業時間内以外のタイミングだと気づきづらいという問題があったので AWS Connect ベースで着電をする実験をしました
    • 機能的には使えることがわかったので、3 月中にチームで運用できるように整えるところをやっていく予定です
  • インタビュー記事がでました
  • 作業用の机等全部入れ替えました
    • かなり昔に買ったダイニングテーブルをずっと使い続けていましたが、大きすぎることやテーブル面の下部に出っ張りが多くて足にあたるのがいやになって新調しました。
    • 購入したものは こちら にまとめておきました。
    • すべてバウヒュッテで統一しました。
    • 実際に組み立てて設置してみると想定外のことは結構発生しまして、いろいろなパーツを追加発注しました。

おわり