コンテナ環境が広まっていくと、アプリケーションやサービスが安定運用できるようになる、という話を耳にします。それはそれで事実だと思うのですが、本当にサービスを安定運用するにはアプリケーションが使うバックエンドも安定運用が必要で、そのあたりの話が飛ばされていることが多いと感じることもあります。 今回のブログエントリはそういう話の例として、Node.js からリレーショナルデータベース（今回は PostgreSQL）を使うアプリケーションでどういった点を考慮すべきか、という例を紹介します。
Node.js から PostgreSQL に接続する、というコード自体は node-postgres という npm パッケージを使うことで簡単に実現できます。具体的な方法もググって容易に見つけることができます。
一方、特にクラウドやコンテナ環境においてはマイクロサービス化を踏まえた設計になっていることも珍しくないと思っています。そのようなケースでは「PostgreSQL がメンテナンス状態になる（接続が切れる）」ことを想定する必要があります。アプリケーションとしては「データベース接続が切断される可能性があり、切断されたら再接続する（それも失敗したら再接続を続ける）」という挙動になるような、ちと面倒な実装が求められます：
そのような具体的に動くサンプルコードを探していたのですが、ピンポイントで見つけることができず、色々試しながら自分で作ってみました。docker で PostgreSQL イメージを起動し、コンテナを止めたり再スタートすることでアプリも再接続することを確認することができるものです：
https://github.com/dotnsf/postgresql_reconnect
なお、以下の内容は PostgreSQL で（一般的なアプリではこれが普通だと思っていますが）コネクションプーリングを使う前提での接続や SQL 実行を想定したコードを紹介します。
【動作確認】
以下 Node.js が導入された PC と、ローカルの docker を使ってアプリケーションの動作確認する場合の手順を紹介します。
まずはソースコード一式を入手してください。上述の Github リポジトリから git clone するか、ダウンロード＆展開して postgresql_reconnect/ プロジェクトを手元に用意します。
まずは docker で PostgreSQL を動かします。起動時に DB を作成しますが、特にテーブルやデータを作ることもなく、単に起動するだけ、です：
↑このコマンドはローカルホストに docker エンジンが導入されている前提で、
・ユーザー名: admin
・パスワード: P@ssw0rd
・データベース名: mydb
・公開ポート番号: 5432
でオフィシャル PostgreSQL イメージをコンテナとして起動するように指示するコマンドです。各指定オプションを変更して動かすことも可能ですが、後述するサンプルソースコードはこの内容で PostgreSQL インスタンスが生成される前提で記述されているため、ここから変更する場合はこの後に紹介するサンプルコードの内容も変更内容に合わせて適宜編集してから実行してください：
まずは切断時の再接続を考慮しないコード: oldapp.js を実行してみます。ちなみに oldapp.js の内容は以下のようになっています（青字部分が PostgreSQL の接続情報、赤字部分が接続部分、そしてピンクが SQL 実行部分です）：
実際に Node.js で動かす場合、まず初回のみ依存ライブラリをインストールするため（Node.js 導入済みの環境で）以下のコマンドを実行します：
そして以下のコマンドで oldapp.js を起動します：
起動すると "server starting on 8080 ..." と表示され、サーバーが 8080 番ポートでリクエスト待ち状態になります。また、この oldapp.js の場合は起動直後に PostgreSQL に接続を試みるので "connected." と表示されます：
上述の oldapp.js の内容からもわかるのですが、このアプリケーションは "GET /" と "GET /ping" という２つの REST API を処理します。前者は単に { status: true } という JSON を返すだけのものです。また後者は接続した PostgreSQL に対して "SELECT 1" という SQL を実行し、その実行結果を返すものです（PostgreSQL に接続できていればなんらかの結果が返るものです）。
試しに前者を実行してみます。ウェブブラウザで "http://localhost:8080/" にアクセスし、{ status: true } が表示されることを確認します：
また後者も実行してみます。同様にウェブブラウザで "http://localhost:8080/ping" にアクセスし、{ status: true, result: { .... } } という文字列が表示されることを確認します：
ここまでは普通に成功するはずです。
ここからが本番です。この状態でアプリケーションを動かしたまま PostgreSQL サーバーを止めてみます。docker コマンドで止める場合は
を実行します（docker デスクトップを使っている場合は稼働中のコンテナの STOP ボタンを押すと止まります）：
この状態で改めてウェブブラウザで各ページにアクセスするとどうなるか？ 期待している挙動という意味では以下のようになると思っています：
・GET / へのリクエストについては（DB を使わないので）{ status: true } を返す
・GET /ping へのリクエストについては（DB が止まっているので）「DB エラー」を返す
・（更に）DB が再稼働したら自動的に再接続して、GET /ping に対して SQL 実行結果を返す
ところが、実はこの時点でサーバーはクラッシュしています。$ node oldapp を実行したターミナルには Exception が表示された上にアプリケーションは終了し、プロンプトが表示されてしまっています：
つまりサーバーがクラッシュしています。したがって GET /ping どころか、GET / へのリクエストもエラーとなってしまうし、稼働していないので自動再接続もできません：
これでは困ってしまいます。簡単なデモ程度が目的の実装であれば oldapp.js の内容でも（とりあえず動くので）いいと思いますが、ある程度安定した連続稼働が求められる実運用を想定するとちょっと心細い状況と言えます。
では oldapp.js と同じ内容で、DB を止めてもアプリケーションが死ぬこともなく、DB が復活したら自動再接続して再び SQL が実行できるようになるような実装はどのようにすればよいでしょうか？ その例が newapp.js です：
青字部分が PostgreSQL の接続情報、赤字部分が接続部分、そしてピンクが SQL 実行部分です（青字部分は全く同じです）。違いを紹介する前にまずは挙動を確認してみましょう。PostgreSQL を再び稼働状態に戻します：
この状態で "$ node newapp" を実行して newapp.js を起動します：
同じようなメッセージが表示されて、リクエスト待ち状態になります。まずは先ほど同様に GET / や GET /ping を実行します（実行結果自体は先ほどと同じです）：
ではここでも同様に PostgreSQL を強制停止してみましょう。先ほどはアプリケーションがクラッシュしてリクエスト待ち状態ではなくなってしまいましたが、今回はプロンプトには戻らず、引き続き待ち受け状態が続くはずです：
この状態で改めて GET / や GET /ping にアクセスしてみます。GET / は変わらず { status: true } を返し、GET /ping は（DB にアクセスできないので） { status: false, error: ... } という内容になりますが、ちゃんとレスポンスを返すことができています：
そして止まっていた PostgreSQL を再度スタートします：
するとアプリケーションが自動的に再接続を行い、少ししてから GET /ping を実行すると、再び SQL 実行が成功した時の画面が表示されます：
これでデータベースにメンテナンスが入っても自動再接続して稼働する、という実用的な挙動が実現できました。
【コード説明】
改めて２つのソースコードを比較します。といっても青字部分は共通なので比較の対象からははずし、赤字の接続部分と、ピンク字の SQL 実行部分を比較します。
まずは前者の自動再接続しない方。接続部分と SQL 実行部分は以下のようでした：
接続処理では単純に接続文字列を生成してコネクションプーリングを生成し、直後に connect() を実行してクライアントを１つ取り出しています。そしてこのクライアントをこの後の SQL 実行時に使いまわしています。
また SQL 実行処理でも SQL 文字列を定義して↑で取り出したクライアントを使って実行しています。処理そのものはわかりやすいのですが、一方でこれといった例外発生を考慮した内容でもありません（そのため DB が止まってしまうケースが想定できておらず、アプリケーションのクラッシュを引き起こしてしまう内容でした）。
一方の後者、例外発生を考慮して、切断後に自動再接続できるようにした方の接続部分と SQL 実行部分は以下のようでした：
まず接続処理ではコネクションプーリングを生成するまでは同じですが、ここではそのまま終了します。connect() を実行してクライアントを取り出す、のは実際に SQL を実行する直前の処理に変更しています。またこのコネクションプーリングを管理する変数 pg を使ってエラーハンドリングを行い、DB 切断時に正しくハンドリングできるようにしています（具体的には数秒待ってから再びコネクションプーリングを生成し、新たに生成したコネクションプーリングに対してもエラーハンドリングを行う、という内容です）。
また SQL 実行時には以下のような処理を加えています：
（１）処理全体を try{ .. }catch{ .. }finally{ .. } で括り、どこで切断しても例外処理できるようにする
（２）try{ .. } 内の実際に SQL を実行する直前に pg.connect でクライアントを取り出す
（３）finally{ .. } 内でクライアントをリリースしてコネクションプーリングに戻す
この３つの処理を加えておくことで DB が突然死んでも正しくハンドリングして再接続（再びコネクションプーリングを作る）を試みるようにしています。また結果的に再接続に時間がかかってしまう場合であってもアプリケーションそのものはクラッシュせずに生き続けるので、（DB にアクセスはできないけど）利用者からのリクエストに返答できるようにしています。
・・・というわけで、公開＆提供しているのはあくまでサンプルですが、この考え方で PostgreSQL サーバーの切断時でも自動接続して連続稼働ができるようになると思っています。また PostgreSQL 以外のコネクションを使う RDB を利用する際にも応用できる内容です。 利用するインフラプラットフォームによってはこういったメンテナンス時の再接続方法について特殊な機能が用意されていることもあるので、必ずしもこういう方法をとらないといけない、というわけではないのですが、一つのベストプラクティス的な内容だと思っています。
自分が痛い目にあったことに関わる内容でもあるので、困っている方のお役に立てば何より。
Node.js から PostgreSQL に接続する、というコード自体は node-postgres という npm パッケージを使うことで簡単に実現できます。具体的な方法もググって容易に見つけることができます。
一方、特にクラウドやコンテナ環境においてはマイクロサービス化を踏まえた設計になっていることも珍しくないと思っています。そのようなケースでは「PostgreSQL がメンテナンス状態になる（接続が切れる）」ことを想定する必要があります。アプリケーションとしては「データベース接続が切断される可能性があり、切断されたら再接続する（それも失敗したら再接続を続ける）」という挙動になるような、ちと面倒な実装が求められます：
そのような具体的に動くサンプルコードを探していたのですが、ピンポイントで見つけることができず、色々試しながら自分で作ってみました。docker で PostgreSQL イメージを起動し、コンテナを止めたり再スタートすることでアプリも再接続することを確認することができるものです：
https://github.com/dotnsf/postgresql_reconnect
なお、以下の内容は PostgreSQL で（一般的なアプリではこれが普通だと思っていますが）コネクションプーリングを使う前提での接続や SQL 実行を想定したコードを紹介します。
【動作確認】
以下 Node.js が導入された PC と、ローカルの docker を使ってアプリケーションの動作確認する場合の手順を紹介します。
まずはソースコード一式を入手してください。上述の Github リポジトリから git clone するか、ダウンロード＆展開して postgresql_reconnect/ プロジェクトを手元に用意します。
まずは docker で PostgreSQL を動かします。起動時に DB を作成しますが、特にテーブルやデータを作ることもなく、単に起動するだけ、です：
$ docker run -d --name postgres -e POSTGRES_USER=admin -e POSTGRES_PASSWORD=P@ssw0rd -e POSTGRES_DB=mydb -p 5432:5432 postgres
↑このコマンドはローカルホストに docker エンジンが導入されている前提で、
・ユーザー名: admin
・パスワード: P@ssw0rd
・データベース名: mydb
・公開ポート番号: 5432
でオフィシャル PostgreSQL イメージをコンテナとして起動するように指示するコマンドです。各指定オプションを変更して動かすことも可能ですが、後述するサンプルソースコードはこの内容で PostgreSQL インスタンスが生成される前提で記述されているため、ここから変更する場合はこの後に紹介するサンプルコードの内容も変更内容に合わせて適宜編集してから実行してください：
まずは切断時の再接続を考慮しないコード: oldapp.js を実行してみます。ちなみに oldapp.js の内容は以下のようになっています（青字部分が PostgreSQL の接続情報、赤字部分が接続部分、そしてピンクが SQL 実行部分です）：
//. oldapp.js
var express = require( 'express' ),
app = express();
var PG = require( 'pg' );
//. PostgreSQL
var pg_hostname = 'localhost';
var pg_port = 5432;
var pg_database = 'mydb';
var pg_username = 'admin';
var pg_password = 'P@ssw0rd';
var pg_clinet = null;
var connectionString = "postgres://" + pg_username + ":" + pg_password + "@" + pg_hostname + ":" + pg_port + "/" + pg_database;//+ "?sslmode=verify-full";
var pg = new PG.Pool({
connectionString: connectionString
});
pg.connect( function( err, client ){
if( err ){
//. 初回起動時に DB が動いていない
console.log( 'no db on startup', err.code );
}else{
console.log( 'connected.' );
pg_client = client;
}
});
//. top
app.get( '/', function( req, res ){
res.contentType( 'application/json; charset=utf-8' );
res.write( JSON.stringify( { status: true }, null, 2 ) );
res.end();
});
//. ping
app.get( '/ping', function( req, res ){
res.contentType( 'application/json; charset=utf-8' );
var sql = 'select 1';
var query = { text: sql, values: [] };
pg_client.query( query, function( err, result ){
if( err ){
console.log( { err } );
res.status( 400 );
res.write( JSON.stringify( { status: false, error: err }, null, 2 ) );
res.end();
}else{
//console.log( { result } );
res.write( JSON.stringify( { status: true, result: result }, null, 2 ) );
res.end();
}
});
});
var port = process.env.PORT || 8080;
app.listen( port );
console.log( "server starting on " + port + " ..." );
実際に Node.js で動かす場合、まず初回のみ依存ライブラリをインストールするため（Node.js 導入済みの環境で）以下のコマンドを実行します：
$ npm install
そして以下のコマンドで oldapp.js を起動します：
$ node oldapp
起動すると "server starting on 8080 ..." と表示され、サーバーが 8080 番ポートでリクエスト待ち状態になります。また、この oldapp.js の場合は起動直後に PostgreSQL に接続を試みるので "connected." と表示されます：
$ node oldapp server starting on 8080 ... connected.
上述の oldapp.js の内容からもわかるのですが、このアプリケーションは "GET /" と "GET /ping" という２つの REST API を処理します。前者は単に { status: true } という JSON を返すだけのものです。また後者は接続した PostgreSQL に対して "SELECT 1" という SQL を実行し、その実行結果を返すものです（PostgreSQL に接続できていればなんらかの結果が返るものです）。
試しに前者を実行してみます。ウェブブラウザで "http://localhost:8080/" にアクセスし、{ status: true } が表示されることを確認します：
また後者も実行してみます。同様にウェブブラウザで "http://localhost:8080/ping" にアクセスし、{ status: true, result: { .... } } という文字列が表示されることを確認します：
ここまでは普通に成功するはずです。
ここからが本番です。この状態でアプリケーションを動かしたまま PostgreSQL サーバーを止めてみます。docker コマンドで止める場合は
$ docker stop postgres
を実行します（docker デスクトップを使っている場合は稼働中のコンテナの STOP ボタンを押すと止まります）：
この状態で改めてウェブブラウザで各ページにアクセスするとどうなるか？ 期待している挙動という意味では以下のようになると思っています：
・GET / へのリクエストについては（DB を使わないので）{ status: true } を返す
・GET /ping へのリクエストについては（DB が止まっているので）「DB エラー」を返す
・（更に）DB が再稼働したら自動的に再接続して、GET /ping に対して SQL 実行結果を返す
ところが、実はこの時点でサーバーはクラッシュしています。$ node oldapp を実行したターミナルには Exception が表示された上にアプリケーションは終了し、プロンプトが表示されてしまっています：
つまりサーバーがクラッシュしています。したがって GET /ping どころか、GET / へのリクエストもエラーとなってしまうし、稼働していないので自動再接続もできません：
これでは困ってしまいます。簡単なデモ程度が目的の実装であれば oldapp.js の内容でも（とりあえず動くので）いいと思いますが、ある程度安定した連続稼働が求められる実運用を想定するとちょっと心細い状況と言えます。
では oldapp.js と同じ内容で、DB を止めてもアプリケーションが死ぬこともなく、DB が復活したら自動再接続して再び SQL が実行できるようになるような実装はどのようにすればよいでしょうか？ その例が newapp.js です：
//. newapp.js
var express = require( 'express' ),
app = express();
var PG = require( 'pg' );
//. PostgreSQL
var pg_hostname = 'localhost';
var pg_port = 5432;
var pg_database = 'mydb';
var pg_username = 'admin';
var pg_password = 'P@ssw0rd';
var retry_ms = 5000; //. retry every 5 sec
var connectionString = "postgres://" + pg_username + ":" + pg_password + "@" + pg_hostname + ":" + pg_port + "/" + pg_database;//+ "?sslmode=verify-full";
console.log( 'connecting...' );
var pg = new PG.Pool({
connectionString: connectionString
});
pg.on( 'error', function( err ){
console.log( 'db error on starting', err );
if( err.code && err.code.startsWith( '5' ) ){
//. terminated by admin?
try_reconnect( retry_ms );
}
});
function try_reconnect( ts ){
setTimeout( function(){
console.log( 'reconnecting...' );
pg = new PG.Pool({
connectionString: connectionString
});
pg.on( 'error', function( err ){
console.log( 'db error on working', err );
if( err.code && err.code.startsWith( '5' ) ){
//. terminated by admin?
try_reconnect( ts );
}
});
}, ts );
}
//. top
app.get( '/', function( req, res ){
res.contentType( 'application/json; charset=utf-8' );
res.write( JSON.stringify( { status: true }, null, 2 ) );
res.end();
});
//. ping
app.get( '/ping', async function( req, res ){
res.contentType( 'application/json; charset=utf-8' );
var conn = null;
try{
conn = await pg.connect();
var sql = 'select 1';
var query = { text: sql, values: [] };
conn.query( query, function( err, result ){
if( err ){
console.log( { err } );
res.status( 400 );
res.write( JSON.stringify( { status: false, error: err }, null, 2 ) );
res.end();
}else{
//console.log( { result } );
res.write( JSON.stringify( { status: true, result: result }, null, 2 ) );
res.end();
}
});
}catch( e ){
res.status( 400 );
res.write( JSON.stringify( { status: false, error: e }, null, 2 ) );
res.end();
}finally{
if( conn ){
conn.release();
}
}
});
var port = process.env.PORT || 8080;
app.listen( port );
console.log( "server starting on " + port + " ..." );
青字部分が PostgreSQL の接続情報、赤字部分が接続部分、そしてピンクが SQL 実行部分です（青字部分は全く同じです）。違いを紹介する前にまずは挙動を確認してみましょう。PostgreSQL を再び稼働状態に戻します：
この状態で "$ node newapp" を実行して newapp.js を起動します：
$ node newapp server starting on 8080 ... connecting...
同じようなメッセージが表示されて、リクエスト待ち状態になります。まずは先ほど同様に GET / や GET /ping を実行します（実行結果自体は先ほどと同じです）：
ではここでも同様に PostgreSQL を強制停止してみましょう。先ほどはアプリケーションがクラッシュしてリクエスト待ち状態ではなくなってしまいましたが、今回はプロンプトには戻らず、引き続き待ち受け状態が続くはずです：
この状態で改めて GET / や GET /ping にアクセスしてみます。GET / は変わらず { status: true } を返し、GET /ping は（DB にアクセスできないので） { status: false, error: ... } という内容になりますが、ちゃんとレスポンスを返すことができています：
そして止まっていた PostgreSQL を再度スタートします：
するとアプリケーションが自動的に再接続を行い、少ししてから GET /ping を実行すると、再び SQL 実行が成功した時の画面が表示されます：
これでデータベースにメンテナンスが入っても自動再接続して稼働する、という実用的な挙動が実現できました。
【コード説明】
改めて２つのソースコードを比較します。といっても青字部分は共通なので比較の対象からははずし、赤字の接続部分と、ピンク字の SQL 実行部分を比較します。
まずは前者の自動再接続しない方。接続部分と SQL 実行部分は以下のようでした：
var pg_clinet = null; var connectionString = "postgres://" + pg_username + ":" + pg_password + "@" + pg_hostname + ":" + pg_port + "/" + pg_database;//+ "?sslmode=verify-full"; var pg = new PG.Pool({ connectionString: connectionString }); pg.connect( function( err, client ){ if( err ){ //. 初回起動時に DB が動いていない console.log( 'no db on startup', err.code ); }else{ console.log( 'connected.' ); pg_client = client; } }); : : //. ping app.get( '/ping', function( req, res ){ res.contentType( 'application/json; charset=utf-8' ); var sql = 'select 1'; var query = { text: sql, values: [] }; pg_client.query( query, function( err, result ){ if( err ){ console.log( { err } ); res.status( 400 ); res.write( JSON.stringify( { status: false, error: err }, null, 2 ) ); res.end(); }else{ //console.log( { result } ); res.write( JSON.stringify( { status: true, result: result }, null, 2 ) ); res.end(); } }); });
接続処理では単純に接続文字列を生成してコネクションプーリングを生成し、直後に connect() を実行してクライアントを１つ取り出しています。そしてこのクライアントをこの後の SQL 実行時に使いまわしています。
また SQL 実行処理でも SQL 文字列を定義して↑で取り出したクライアントを使って実行しています。処理そのものはわかりやすいのですが、一方でこれといった例外発生を考慮した内容でもありません（そのため DB が止まってしまうケースが想定できておらず、アプリケーションのクラッシュを引き起こしてしまう内容でした）。
一方の後者、例外発生を考慮して、切断後に自動再接続できるようにした方の接続部分と SQL 実行部分は以下のようでした：
var retry_ms = 5000; //. retry every 5 sec var connectionString = "postgres://" + pg_username + ":" + pg_password + "@" + pg_hostname + ":" + pg_port + "/" + pg_database;//+ "?sslmode=verify-full"; console.log( 'connecting...' ); var pg = new PG.Pool({ connectionString: connectionString }); pg.on( 'error', function( err ){ console.log( 'db error on starting', err ); if( err.code && err.code.startsWith( '5' ) ){ //. terminated by admin? try_reconnect( retry_ms ); } }); function try_reconnect( ts ){ setTimeout( function(){ console.log( 'reconnecting...' ); pg = new PG.Pool({ connectionString: connectionString }); pg.on( 'error', function( err ){ console.log( 'db error on working', err ); if( err.code && err.code.startsWith( '5' ) ){ //. terminated by admin? try_reconnect( ts ); } }); }, ts ); } : : //. ping app.get( '/ping', async function( req, res ){ res.contentType( 'application/json; charset=utf-8' ); var conn = null; try{ conn = await pg.connect(); var sql = 'select 1'; var query = { text: sql, values: [] }; conn.query( query, function( err, result ){ if( err ){ console.log( { err } ); res.status( 400 ); res.write( JSON.stringify( { status: false, error: err }, null, 2 ) ); res.end(); }else{ //console.log( { result } ); res.write( JSON.stringify( { status: true, result: result }, null, 2 ) ); res.end(); } }); }catch( e ){ res.status( 400 ); res.write( JSON.stringify( { status: false, error: e }, null, 2 ) ); res.end(); }finally{ if( conn ){ conn.release(); } } });
まず接続処理ではコネクションプーリングを生成するまでは同じですが、ここではそのまま終了します。connect() を実行してクライアントを取り出す、のは実際に SQL を実行する直前の処理に変更しています。またこのコネクションプーリングを管理する変数 pg を使ってエラーハンドリングを行い、DB 切断時に正しくハンドリングできるようにしています（具体的には数秒待ってから再びコネクションプーリングを生成し、新たに生成したコネクションプーリングに対してもエラーハンドリングを行う、という内容です）。
また SQL 実行時には以下のような処理を加えています：
（１）処理全体を try{ .. }catch{ .. }finally{ .. } で括り、どこで切断しても例外処理できるようにする
（２）try{ .. } 内の実際に SQL を実行する直前に pg.connect でクライアントを取り出す
（３）finally{ .. } 内でクライアントをリリースしてコネクションプーリングに戻す
この３つの処理を加えておくことで DB が突然死んでも正しくハンドリングして再接続（再びコネクションプーリングを作る）を試みるようにしています。また結果的に再接続に時間がかかってしまう場合であってもアプリケーションそのものはクラッシュせずに生き続けるので、（DB にアクセスはできないけど）利用者からのリクエストに返答できるようにしています。
・・・というわけで、公開＆提供しているのはあくまでサンプルですが、この考え方で PostgreSQL サーバーの切断時でも自動接続して連続稼働ができるようになると思っています。また PostgreSQL 以外のコネクションを使う RDB を利用する際にも応用できる内容です。 利用するインフラプラットフォームによってはこういったメンテナンス時の再接続方法について特殊な機能が用意されていることもあるので、必ずしもこういう方法をとらないといけない、というわけではないのですが、一つのベストプラクティス的な内容だと思っています。
自分が痛い目にあったことに関わる内容でもあるので、困っている方のお役に立てば何より。
