PostgreSQLへ~技術開発部の杉山です。PostgreSQLへの移行における、事前障害試験の内容をメモしておこうと思います。良いタイミングなので導入後にテストし難い障害試験を実施しておきました。疲れてきたらリフレッシュにウクレレを1~2曲弾いて気分転換しています。移行する事で、常に安定したサービスを利用者及び提携先に提供する。可用性が99.99%まで高まり、サービスに対する機会損失を削減する事が出来る。障害発生時の切り替えがシンプルでアプリケーション側の対応も不要で属人的でない。Auroraに移行しても、現状のレプリケーション構成とコストは微増程度で変らない。エンジニアのインフラ対応工数が減るので、トータルで見るとTCOは削減出来る。databasesで対応。現在の構成と課題LCLでは、これまでも、サービス開発と並行してサービスを安定稼働させる為の取り組みを適宜実施してきました。幾つかの課題を抱えていた為、体制も整ってきたこのタイミングで入れ替える事に致しました。pg_poolの構築・運用に慣れているメンバーで無いと分かり難い。障害パターンにより、適切にフェールオーバー出来ない事がある。AWS障害発生時に、アベイラビリティゾーン間でのフェールオーバーの手間。マスターDB障害発生時に、レプリケーション構成を組み直すのがDBA不在だと大変。データ障害以外の場合は、障害発生時に工数をかけたくない。('node')フェールオーバー処理とエラー発生時の挙動のみの確認なので以下の環境を準備INSERT処理に関してはシンプルなテーブルとスクリプトを準備。LOOPし続けて参照エラーを確認。Rails側のエラーは、テスト環境にアクセスしてRailsのログを確認。ポートフォワードしているので、実際にはローカルホストではありません。回目で処理がエラーになっている事が確認出来ます。LOOPで確認したのですが参照エラーは発生しませんでした。回目と1797回目で処理がエラーになっている事が確認出来ます。TTLの影響を受けるのはこちら。Loopの2233回目で処理がエラーになっている事が確認出来ます。(書き込み)トランザクションを利用して、長時間実行しているバッチ処理があるので、バッチ処理実行時の再起動とフェールオーバーが発生した場合の状況を確認。再起動が発生した場合トランザクションはサーバーが切り替わるので、エラーになりロールバックされる。トランザクションは再起動で接続が切れるので、エラーになりロールバックされる。トランザクションが破棄され、ロールバックされているのでデータは更新されていません。exitでトランザクションが破棄されているのでデータが更新されて無い事が確認出来ます。クラスターの耐障害性をテスト出来る様になっています。上記の検証と合わせて、以下の障害試験もせっかくなので実施しました。互換データベースのクラッシュがシミュレートされます。クラスターのプライマリインスタンスにあるディスパッチャーのクラッシュがシミュレートされます。クラスターのクラスターボリュームに対して更新を書き込みます。インスタンスのディスパッチャーの両方のクラッシュがシミュレートされます。('instance')書き込み、読み込み専用ノード共に実行しましたが、ダウンタイムという観点では書き込み・読み込み共に大きな差異はありませんでした。プロンプトでSQLコマンドを実行して、再接続したら既にアクセスする事は可能でした。|Auroraのログをawsのシェルで確認して見ます。text読み込み専用ノードの場合のログを見ると,4秒程度しか差異が無い事が確認出来ました。('dispatcher')以下のログが記録されていて、ダウンタイムという観点ではインスタンス障害と大きな差異はありませんでした。無しAuroraのエラーログでは、kill9でプロセスが強制終了されている事が確認出来ました。row)Loopしていた書き込み処理も2回程、エラーになりましたが、2~5秒の瞬断と言ったところでしょうか。アプリケーション側でリトライ処理を入れておけば、カバー出来る位の間隔かもしれません。Loopの1151回目と1152回目で処理がエラーになっている事が確認出来ます。('node')インスタンスとディスパッチャーの両方のクラッシュがシミュレートされるので、若干ダウンタイムは長いですが5秒程度で復旧している事が確認出来ます。回目で3回程失敗している事が確認出来ます。connections障害テスト中は管理コンソールには以下の様なログが記録されます。上記テスト中にRailsの検証環境でもAuroraを参照していましたが、障害発生時間が5秒未満だった為かエラーログは有りませんでした。バッチも1日1回のもので無ければ、再実行で処理されるので問題は無い。1日1回の処理のバッチがエラーになった場合は、そちらをマニュアルで再実行する。提供しているサービスによってはメンテナンス時間は気を付ける必要は有ります。以下、id列でソートして次のidから前のidの差分を算出した場合です。idの欠番が発生していました。rows)欠番している部分は以下のように書き込みのLAGが約5秒発生しています。(digにて確認)接続先は、CNAMEなのでTTL(5秒)が障害発生時の影響を受ける事もあるかと思います。データベースサーバーの負荷によってもフェールオーバーの時間は変わってくると思います。今回の検証を通じて、おおよそ~30秒程度のダウンタイムを目安に運用して行けば問題無いという事が分かりました。目標値としては、99.99%(年間ダウンタイム:52分34秒)なので100回/年ダウンしてもまだ大丈夫そうです。10.1.1.101バックアップデータベースがどんなに優れたソフトウエアでも、人的障害には対応していません。ビジネス要件に応じたバックアップを適切に取得してリカバリー出来るようにしておきましょう。最後に今年1年は本当に色々な事があり、多くの方が色々な苦労をされたと思います。日々を過ごして行ければと思います。LCLエンジニアチームの杉山です。技術開発部の杉山です。技術開発部の杉山です。1検索はてなブログをはじめよう!lcl-engineerさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。