インターネット製品リリースのグレースケールリリース

クズども · 掲載地 2017/03/09 15:48:27

上の写真はテンセントのグレースケールリリースで、一般ユーザーはアクセス可能で、アリババクラウドサーバーにはアクセスできず、pingも正常、解像度IPも正常です

ただアクセスが難しいだけで、テンセントもグレースケールのリリースを好んでいるのがわかります...

1. なぜグレースケールリリースなのか

インターネットサービスは頻繁に変更され、リリースサイクルも短いです。スピードとクオリティを両立させるのはいつも難しいです。
グレースケール出版は出版リスクを減らし、影響範囲を縮小できます。
テストへの依存を減らし、オフラインの自己検査におけるデータ構築コストを削減します。
ログを中央で監視し、全文を公開するのは便利です。各層での負荷分散の役割のため、通話リンクを完全に追跡するのは困難です。
グレースケールのテストアカウントを使い、テストアカウントがクリアされた後にグレースケールの実際のユーザーアカウントを使うことで、公開のリスクと影響をさらに減らせます。
簡単にロールバックできます。

グレースケールリリースでは解決できない問題

上記の「許容範囲の影響」は回復可能でなければならないことを強調すべきです。例えば、APIは一定期間呼び出せませんが、修復後は正常に呼び出すことができます。ユーザーデータ(製品情報、注文情報など)の永久的な喪失や破壊は耐えられません。したがって、インターネット企業の設計者は、ユーザーデータの喪失を手動介入で、1時間前から1週間前までの状態に戻す責任があります。これは、ユーザーデータの定期的なバックアップや運用ログの作成などによる運用システムの障害による損失時には、手動介入によってです。

TIPS:まずアカウントのグレースケールポリシーをテストし、実際のユーザーのデータを損傷または失うリスクを減らしましょう。

2. どのような効果が期待されるか?
変更の有無にかかわらず、特定のリクエストは私たちのバージョン(グレースケール版)にルーティングされ、観察と検証が行われることを望んでいます。

3. グレースケール戦略
実際、リクエストはグレースケール版(グレースケールマシン)にルーティングされるべきです。これはしばしばビジネスと強く関連しています。例えば、APIに関しては一般的に以下の要件があります。

特定のユーザー(例:テストアカウント)
特定のアプリ(例:テストアプリやパートナーアプリ)
特定のモジュールやインターフェース(グレースケールが必要なインターフェースは一部だけで、グレースケールは一般的にAPIコンテナの修正であり、重要でないAPIもグレースケールテストに使用されます)。）
特定のマシン(一部のリクエストIPはグレースケールマシンに転送されます)
4. グレースケールスキームの議論
解決策1:コードレベルは合意されたフラグで判断され、旧フラグと新フラグを動的に切り替える - Amazonのアプローチ

実施:

スイッチをコードに埋め込み、if-elseの判断を下し、グレースケールが必要なマシンではスイッチをオンに設定し、そうでなければオフにします。各リリースには2つのバージョンがあります。

価値

高速ロールバックで、システムの再公開や再起動は不要です。
短所

コードに従う傾向を持ちましょう。
分岐論理は複雑さをもたらします。
この方法は、私がアリババにいたときに著者が使ったもので、商品のデータベースをOracleからMySQLに切り替え、状態変数を制御していました。これによりスムーズな移行効果が得られます。

オプション2:プレリリースマシン - アリババの実践

実際、これは本当の意味でのグレースケールではありません。このプレリリースマシンは内部IPであり、外部サービスがないからです。検証にはドメインバインディングが必要です。しかし、データは完全にオンラインにあります。つまり、これはGrayscaleマシンにアクセスできるユーザーや内部テストユーザー向けのシンプルなアプローチです。実際、API側にも同様のアプローチがあり、それが私たちのGamma環境であり、外部の協力ユーザーがテストに協力しやすくするためにGammaマシンのドメイン名も提供しています。

価値

簡単です
短所

マシンを廃棄する(これはプレリリース終了後に本番環境に投入でき、プレリリース中にnginxから削除できますが、O&Mサポートが必要です)。）
柔軟性が足りません
IDLサービスはアクセス層マシンでのみ使用可能であり、IDLサービスは別途考慮する必要があります。
オプション3:SET展開

1. サービスごとに分離して展開する

例えば、現在のAPIコンテナの実践では、デプロイの細分度をAPIレベルまで達成でき、フロントエンドはnginxに従って順に進められます。たとえば：

マイクロショッピングAPIコンテナ:api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API コンテナ:api.yixun.com
オンラインショッピングAPI Container:api.buy.qq.com
上記は大規模なビジネスレベルでの孤立した展開です。さらにモジュールレベルに細化することも可能で、例えば仮想サービスeコマースのAPIはPaipaiの下にあるサブビジネスモジュールですが、WeChatと連携しているため訪問数が大幅に増加しています。Paipaiの他の事業に影響を及ぼさないため、ここでのAPIはそれぞれに別々に2台のマシンを展開し、nginxは仮想APIアクセスを抽出するように設定できます。

Virtual APIコンテナ:http://api.paipai.com/v2/virbiz

このようにして、バージョンをリリースする際には、まず最もビジネスボリュームが少ないYixunを選んで公開し、その後問題がないことを確認すると、他のすべてのプラットフォームを使うことができます。

2. ユーザー隔離による展開

これはオープンプラットフォームにはあまり適していませんが、SNSのようなアプリケーションシナリオには非常に適しています。例えば、QQシステムはユーザー番号セグメントに応じて複数のセットに分割されており、各セットには1億個連続した番号が含まれています。最新のQQ数が10億近くであると仮定すると、合計10のセット(セット1からセット10)となります。このようにして、毎回公開するSESの中から1つを選べ、高レベルのQQはあまり重要でないため、SET10が最初にリリースされます。

価値

事業部門全体で影響を最小限に抑えた孤立した展開。自動的にグレースケール出版をサポートします。
短所

グレースケールの粒度は、一般的に大きい孤立展開の粒度に依存します。
中央集権的な展開と比べて機械の無駄遣いです。
各事業部門のバージョンが一貫性に欠ける可能性があり、統合管理には適していません。
導入や展開には一定のコストがあります
スキーム4:動的ルーティング

方法:グレースケールポリシーを使い、ロードバランスの挙動に影響を与え、グレースケールサービスのIPアドレスとポートをグレースケールポリシーに従って返すように柔軟に設定できます。

バックオフィスIDL付きのサービスグレースケールに適しています。

価値

柔軟で、コントロールしやすい。
短所

現在の構成センターとL5自体は指定されたルーティングポリシーを考慮しておらず、スケーラブルでないため、それらの外で開発する必要があります。
APIのメタデータソースは比較的分散しており、現在APIおよびIDLのメタデータ、APIレベル、頻度制限は異なるデータソースに分散しており、現在はグレースケールのルーティングデータソースを追加する必要があります。

グレースケールのnginx+luaを公開する方法は一般的に3つあり、nginxはクッキーごとに配布され、nginxは重みに応じて割り当てられます。
nginx+luaは訪問者のIPアドレスで区別されます。なぜなら、企業はIPアドレスをエクスポートするため、ウェブサイトは旧バージョンか新バージョンのいずれかでアクセスされるため、この方法には適していません
nginxは重みに基づいて重みを割り当てるため、実装は簡単で試すことができます
nginxはクッキーに基づいて分割し、GrayScaleはユーザーごとに公開します

インターネット製品リリースのグレースケールリリース

関連記事

閲覧したセクション