どちらも読み取れるため、この状況に問題はありません。形式変更のシリアル化を説明しましたが、一般的な技術は前述のプロトコルの変更に関するセクションに記載したすべての状況に適用されます。秒に増やす必要があった過去のシナリオを振り返ってみましょう。秒おきに送信し続けます。秒間隔に変更できます。フェーズのデプロイ手法に従う場合の注意事項について説明します。フェーズデプロイに該当します。多くのデプロイツールでは、変更が適用されたホストの数が少なければデプロイは成功とみなされ、正常とレポートされます。いうデプロイ設定があります。読み取るようアップグレードされていることです。フェーズの終了後にデータが読み取られません。そのため、準備フェーズではすべてのサーバーに変更が適用されたことをはっきりと確認します。開発時に、複数のマイクロサービスにまたがる膨大な数のサーバー間の通信プロトコルを変更することを決定しました。すべてのサーバーが準備フェーズに達してからアクティベートフェーズに進むよう、すべてのマイクロサービス間でデプロイを調整しました。つのサーバーではっきりと確認しました。つの各フェーズではロールバックを安全に実行できますが、両方の変更をロールバックすることはできません。形式のデータが書き込まれます。したがって、念のため準備フェーズとアクティベートフェーズの間に長い時間を空けることにしています。この期間は待機期間と呼ばれ、通常は数日間に設定されます。待機期間を設定することで、旧バージョンへのロールバックが必要な事態を回避します。読み取るソフトウェアの機能を安全に削除できなくなります。書き直されたことを確認した後で削除する必要があります。この処理はバックフィルと呼ばれます。このために、サービスでのデータの書き込みおよび読み取り中に同時に実行できる追加のツールが必要になる場合があります。シリアル化のベストプラクティス多くのソフトウェアでは、永続化やネットワーク上での転送を目的としてデータのシリアル化が行われます。ソフトウェアの進化に応じて、シリアル化のロジックが変更されるのは一般的なことです。これらの変更には、新しいフィールドの追加や形式の完全な変更が含まれます。年月を積み重ねる中で、シリアル化で従うべきベストプラクティスがいくつか確立されました。通常、カスタムシリアル化形式は開発しません。カスタムシリアル化の初期ロジックは影響が少なく、むしろパフォーマンスを向上させる場合もあるかもしれません。確立されたフレームワークではすでに解決されている問題が発生します。安全機能を活用できます。変更ごとに、固有のバージョンをシリアライザに明示的に割り当てます。この処理は、ソースコードやビルドのバージョニングに関係なく行います。シリアライザバージョンをシリアル化されたデータとともに保存するか、メタデータに保存します。古いバージョンのシリアライザは、新しいソフトウェアでも引き続き機能します。通常、書き込まれたデータまたは読み取られたデータのバージョンのメトリクスを出力することは有用です。エラーがあった場合に、オペレータに可視性が提供され、トラブルシューティング情報を確認できます。バージョンにも適用されます。制御できないデータ構造のシリアル化を回避します。アップグレードしようとすると、そのようなクラスの基盤となる実装が変更され、逆シリアル化が失敗する可能性があります。このリスクは、チーム間で共有されるライブラリのクラスにも当てはまります。通常、シリアライザは不明な属性の存在を許可するように設計されています。可能な場合、シリアライザはデータを書き戻す間、不明な属性を保持します。この処理により、新しいバージョンのソフトウェアを実行するサーバーによってシリアル化中に新しい属性がデータに追加された場合でも、古いバージョンを実行するサーバーが同じデータを更新する際に属性が消去されることはありません。フェーズデプロイは必要ありません。多くのベストプラクティスと同様に、ガイドラインはすべてのアプリケーションとシナリオに適用できるわけではないことにご注意ください。変更をロールバックしても問題がないことを確認する一般的に、ソフトウェアの変更をロールフォワードおよびロールバックしても問題ないことを、アップグレード-ダウングレードテストを通じて明示的に検証します。この処理においては、本番環境を代表するテスト環境をセットアップします。長年にわたり、テスト環境をセットアップする際に避けるパターンをいくつか特定してきました。変更がテスト環境のすべてのテストに合格したにもかかわらず、本番環境に変更をデプロイするとエラーが発生することがあります。したがって、すべてのデプロイはアトミックであり、異なるバージョンのソフトウェアを同時に実行する可能性は排除されていました。現在は、テスト環境で本番環境ほどのトラフィックが見られない場合でも、本番環境と同様に、各サービスの背後にある異なるアベイラビリティーゾーンの複数のサーバーが使用されます。倹約が推奨されますが、品質の保証に関しては当てはまりません。別のケースでは、テスト環境に複数のサーバーがありましたが、ただし、テストを高速化するために、すべてのサーバーにデプロイを一括して実行していました。このアプローチでは、ソフトウェアの古いバージョンと新しいバージョンが同時に実行されることも回避されており、ロールフォワードでの問題は検出されませんでした。現在は、すべてのテスト環境と本番環境で同じデプロイ設定を使用しています。マイクロサービス間の調整を伴う変更については、テスト環境と本番環境のマイクロサービス間で同じデプロイ順序が維持されます。ロールフォワードとロールバックの順序は異なる場合があります。通常、シリアル化のコンテキストでは特定の順序に従います。ロールフォワード中は読み込みが書き込みに先行し、ロールバック中は書き込みが読み込みに先行します。テスト環境と実稼働環境の両方で、該当する順番で処理が行われます。テスト環境のセットアップが本番環境に類似している場合は、可能な限り厳密に本番トラフィックをシミュレートします。短時間で連続して作成されて読み込まれます。すべて継続して実行されます。各段階は、潜在的なバグを特定するために必要な期間継続されます。回実行するのに十分な時間になります。最初の段階では、フリートの約半分に変更をデプロイして、ソフトウェアバージョンを共存させます。次の段階では、デプロイを完了させます。番目の段階では、ロールバックデプロイを開始し、すべてのサーバーが古いソフトウェアを実行するまで同じ手順を実行します。これらの段階でエラーや予期しない動作がなければ、テストが成功したとみなされます。まとめお客様へのサービス提供の中断なしにデプロイをロールバックできるようにすることは、サービスの信頼性を高めるうえで不可欠です。ロールバックの安全性を明示的にテストすることで、エラーの発生しやすい手動分析に依存する必要がなくなります。つの変更に分割します。「ソフトウェアデプロイの自動化」を参照してください。プリンシパルエンジニアです。複数のサービスに取り組んできました。リードエンジニアです。問題に取り組んでいました。がい、年齢、その他の属性によって差別することなく、平等に採用選考の機会を提供しています。