Tech

JJUG CCC 2018 Springでレビューに関する話をしました

  • このエントリーをはてなブックマークに追加

発表スライドが映らなくてめっちゃ焦りました。スタッフの人がとても親切で何種類かの変換コネクタを用意してくれたりと、とても親切で助かりました。

お陰様で満席で立ち見も出て、見に来てくださった方々ありがとうございます。

私はオタクなのでとても早口になってしまい、またマイクも上手く使えずに反省点が多かったなと思います。（資料の枚数が少ないと、ゆったり喋るんですがあのペースで話さないと間に合わなかったorz）

何事に置いてもそうなのですが、対象となる組織、文化、背景、状況が異なれば大事にするべき観点は異なります。制度や仕組み、プログラムやパラメータなど、そのまま持っていくのでは無く、エッセンスを抽出して咀嚼してから必要な養分を取り込むという事が大事です

質問に関する補足です

その前に、
スライドに社名をいくつか出していますが、宣伝目的ではなくて、一般的な広告システムと違って組み合わせ最適化のフェーズ(Allocation)があるから処理が大変なんだよという事を言いたかったのです。宣伝はしてないです!!

レビューの観点には冪等性も大事やぞという指摘

その通りだと思います!!

撤退可能ってどういう事?

ロールバック可能な単位で設計やリリースをしましょうという事です。

具体的には、一度投入して問題があった時に例えば外部リソース(DB)の値を変に上書きしちゃって戻すに戻せないとか、ぶっつけ本番+お客さんにプレス打って戻しづらいとかが無いようにする事です。

ロールバック出来る事と、お金（リソース投入）でスケールする事の2つが担保されていると、失敗時の戦術も増え、比較的気軽に投入できます。

AtomicLongは何故問題なの?

LongAdderというクラスがあるので、そちらを使って欲しいのです。前提としては、readとwriteの比率のうち、writeが圧倒的に多い場合です。

パフォーマンスカウンタを例にすると、Writeは大量に発生しますが、Readは定期的な吸い上げで良いのでそういうケースに効果覿面です。

ELBの後ろにnginxがあるのは何故?

いくつか理由があります。

  • 同じドメインで静的コンテンツをいくつか配信している
  • Gzip処理をアプリケーションの外に逃がすため(アプリケーションの本来の責務ではないため)
  • もぐら叩き対策

もぐら叩きは私が勝手に名付けた現象です。負荷が高まったときにアプリケーションサーバのHTTPスレッドが枯渇すると、ELBのヘルスチェックにも応答が出来なくなってしまいます。アプリケーションサーバは2つのPortをListenしており、ServiceポートとAdminポートがあります。また、ServiceポートだけをInstanceの外部に公開しています。

ELBのヘルスチェックに失敗すると、ELBからInstanceが外れてしまいます。只でさえリソースが足りないのにELBから外れるとさらに状態がきつくなります。複数のInstanceがELBから抜ける、入るを繰り返し行うようになります。このようにシステム全体がなかなか復帰しない状態に陥っていまう事が多々ありました。

これを避けるために（被害を少しでも抑えるために）、

  • NGINXのレイヤーでヘルスチェックを終えてしまう
  • もしくはnginxのreverse proxyでadminポートのpingを叩くようにします。(adminの1つのendpointだけを外に公開する)

もちろん超高負荷時にはHTTPスレッドが枯渇している事に変わりはないので、アプリケーションサーバ側のバックログにも積めない状態になればnginxの408エラーが発生します。ただし、ELBから抜けることは無いので全体の処理量はそのままを維持することが出来、結果的に早く復帰します。

これを個人的にもぐら叩き対策と呼んでいます。

自前実装するのはなんで?

ソースが公開されているものは多いですが、遅かったり、該当のケースに適用しづらいのが殆どです。無ければ作れば良いじゃんの精神です。

例えばJavaのcommonsの実装なんて遅いので、そういうのは自前で実装し直します（主に僕の隣に座っている人が）。昔、”よくこれでcommonsを名乗れるな”と過激な発言をしていた事もありますが、もう大人になりました。

参考↓

ガチレビューするとリリース遅くならないの?

遅くはなりますが、参考までに結構前の資料ですがリリース頻度のグラフです。

レビューが細かすぎない?

オンライン処理、バッググラウンド処理、リクエストの最初の1回だけ、Filterや予測処理のループの中なのかで、ある程度指摘するレベルを変えています。
また局所最適化と思われるかもしれませんが、こういう細かい内容が積み重なってボディーブローのように性能を引きずります。それとは別にアルゴリズムの改善や、アーキテクチャの変更は随時行っています。そういう話はJavaとは関係ない話なのでセッションの中では省きました。

この内容で収益を支えるってどういうこと?

広告業界には、トラブル時に3倍返しという良くわからない習慣があります。（目先の謝罪よりも貸しを作って未来に繋げる仕事をする方が私は好きなので、こういう習慣は嫌いですけどね）
また、ピーク時に一発障害を出すだけで、売上げは大きく下がりますし信用も落とします。それに加えて3倍の損害金。レビューを通して技術力(とビジネス力)を底上げし、プロダクトの品質を保つことが結果として収益を支える事に繋がります。

ある程度の防御力を備える事で、多少の無茶が出来るようになります。

もし、どうやって収益を上げるか、どうすれば収益が倍増するかのお話を期待していた方には申し訳ないです。（そういう話はどうやって広告パフォーマンスを最適化するかという話なので、また分野は別になります。他の場所で別のメンバーが話すかもしれません。）