App Service（Microsoft Azure）とAzure SQL DatabaseのReconfiguration対応
概要
- Azure環境でシステム開発している中で、Reconfigurationという現象に遭遇したので、その時の対応についてまとめる
Reconfigurationについて
- Azure SQL Databaseには、サービスの仕様としてReconfigurationというものがある
- Reconfigurationが発生すると、数秒〜数十秒の間、DB接続ができなくなる
- Reconfigurationは、不定期で発生する（現状だと1ヶ月に2、3度）
- Reconfigurationそのものは、安定したDBの稼働のために必要なものらしい
- Azure SQL Databaseを使用するには、Reconfigurationが発生することを前提で開発する必要がある
[SQL Database] Reconfiguration (リコンフィグレーション) は悪ではない。 – Microsoft SQL Server Japan Support Team Blog
環境
本番環境
- Azure App Service（Windowsサーバ）
- PHP5.6
- Lumen
- Azure SQL Database（SQL Server）
開発環境
- vagrant（CentOS）
- PHP5.6
- Lumen
- Azure SQL Database（SQL Server）
Microsoftの公式ドキュメントの対処方法
- Microsoftの公式ドキュメントでは、Reconfgiuration発生を検知し、wait後にリトライを実装する流れを推奨。
- Reconfiguration発生時に使用した接続は使用できないため、改めて接続し直す必要がある。
テスト方法
- 基本的には、Reconfigurationは不定期に発生するが、意図的に発生させることも可能。
- Azure SQL Databaseのプランを変更することで、プランが切り替わる間の数秒間だけReconfigurationが発生。
- Azure Portal上からプラン変更して、SQL実行を連続して実行することでテスト可能。
ハマるポイント
Reconfigurationの判断
- 本番でDB接続エラーが発生したときに、それがReconfigurationによるものなのかは現在MSサポートに問い合わせる必要がある。 以前までは、sys_event.logに出力されていたらしいが、現在は出力されない。
- Microsoft公式ドキュメントでは、Reconfiguration発生の判断をSQLのERRCODEで制御する方法を記載しているが、コネクションプーリングが有効になっていると古いコネクションを使用することでERRCODEに値が入らないことがある、そのときには、SQLSTATEしか入っていないため、そちらで判断する。（これはPHP以外の言語では大丈夫かも。ドライバの問題な気がする。）
リトライ処理をしても同様の接続エラーが発生
- Lumenでは、リクエスト単位でPDOをキャッシュする機構がある
- Lumenの機構を改修して、Recofiguration発生時にのみ、PDOを再生成して失敗したSQL実行という流れを単純に作って対応したが、 Reconfiguration発生時と同様の接続エラーが発生
- PDOを再生成しても内部ではReconfiguration発生時のプールを使用しているため、エラーが発生する
App Serviceのコネクションプーリングの制御
- App Serviceのプラン（サーバスペック）によって、プールの最大数などが決まる仕様になっている
- PHPからプールを破棄するAPIなどは用意されていない
- PHPからアクティブなプール数を取得するAPIなどは用意されていない
- コネクションプーリングを無効化すると、その都度確実に接続しにいくため、エラーが発生し続けることはない
- 但し、遅くなる。
最終的な対応方法
- 基本方針として、コネクションプーリングを一律無効化するのは、パフォーマンスの観点からNGなため、デフォルトはプールを有効化
- 現状は対応1でも問題なく動いているため、様子見。これでも駄目な場合、別途キューのプロセス管理が必要になるが、対応2を検討
対応1
- Reconfigurationを検知したときに、wait後、コネクションプーリングを無効化したPDOを生成し失敗時のSQLを再実行
対応2
- Reconfigurationを検知したときに、システム全体でコネクションプールを無効化するように制御（PDO生成周りの処理改修）
- キューに90秒後コネクションプールを有効化する処理を追加（プールの生存期間が60秒なため、若干の余裕を持たせる）
GitHubのリポジトリ（Issue）移行
移行方法
移行プログラム
処理概要
- GitHub APIを使用して移行元からIssue周りのデータをGetし、移行先のリポジトリへPostしていく流れ
- Issueに必要なマイルストーンやラベルは最初にまとめて移行する
- Issueは1件ずつPostして、それに紐づくコメントもその都度取得してPostする
- Issueもある程度の件数になると、GitHubAPIが途中でエラーになることがあるため、簡易的なリトライ処理を実装
- リトライ処理時は、前回とまったIssue番号を設定して、処理フローを切り替えて再実行とする（簡易的なので、コメントアウトを切り替えて対応）
プログラムの仕様
移行スクリプトを書いていく中ですべて完全に移行するのは難しく、割り切りが必要になった。
- IssueのLabelとMilestoneはすべて移行する
- Issueの移行は、移行元と移行先で同一のIssue番号を付与する
- Postした順にIssue番号が採番されるため、移行元からIssueデータをソートして取得
- Pull Requestは簡易的な移行とする
- GitHubのIssueとPull Requestは1種類のidで管理されており、移行元と移行先のIssue番号をあわせるため、移行元でPull Requestだったものは、タイトルにその旨記載して空のIssueとして登録
- Issueのコメントで使用している画像添付については、移行を諦める
macでディレクトリの差分抽出
これまで
Macで2つのディレクトリの差分を見る時に、Kaleidoscope — File comparison for Mac を使用していたが、開発端末が変わるタイミングで改めて他の方法がないか検討。
検討結果
開発ではPHPStormを使用していて、プロジェクトビューから対象ディレクトリを指定することで差分を取ることも可能だが、コマンドラインでもいけるということでメモ。
コマンドラインは以下。
/Applications/PhpStorm.app/Contents/MacOS/phpstorm diff dir1 dir2
問題なくいけそうなので、aliasを設定。
最近はfish shellを使い始めたので、以下のような感じでconfig.fishに設定。
balias psd '/Applications/PhpStorm.app/Contents/MacOS/phpstorm diff'
lumenのログ出力制御（rotateの方法）
デフォルトの設定
- デフォルト設定のままだと、「ルート/storage/logs」配下に
lumen.logが吐かれる。
全てのログがこの1ファイルにずっと吐き続けられる。
laravelの設定
- 「ルート/config/app.php」のlog（キー値）に対して設定してあげると
rotateの制御をしてくれるみたい。
lumenでの対応
やりたいこと
- 日付単位でrotateさせたい
- ログを今後管理するのを考えた時に、日付はファイル名に付加しないで日付のディレクトリを配置して、その下に吐かれるようにしたい
対応方法
- 「ルート/app」直下にApplication.php（以下のファイル）を作成
<?php
namespace App;
use Monolog\Logger;
use Laravel\Lumen\Application as LumenApplication;
use Monolog\Handler\StreamHandler;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\NewRelicHandler;
use Monolog\Handler\RotatingFileHandler;
class Application extends LumenApplication
{
/**
* Register container bindings for the application.
*
* @return void
*/
protected function registerLogBindings()
{
$this->singleton('Psr\Log\LoggerInterface', function () {
return new Logger('lumen', $this->getMonologHandler());
});
}
/**
* Extends the default logging implementation with additional handlers if configured in .env
*
* @return array of type \Monolog\Handler\AbstractHandler
*/
protected function getMonologHandler()
{
$errorLogger = new RotatingFileHandler(storage_path("logs/{date}/error.log"), 0, Logger::ERROR, false);
$infoLogger = new RotatingFileHandler(storage_path("logs/{date}/info.log"), 0, Logger::INFO, false);
$handlers = [];
$handlers[] = $this->setLoggerFileFormat($errorLogger);
$handlers[] = $this->setLoggerFileFormat($infoLogger);
return $handlers;
}
/**
* Loggerのファイル名と日付フォーマットを設定
*
* @param $logger
* @return mixed
*/
private function setLoggerFileFormat($logger) {
$logger->setFilenameFormat('{filename}', 'Ymd');
$logger->setFormatter(new LineFormatter(null, null, true, true));
return $logger;
}
}
$app = new App\Application(
realpath(__DIR__.'/../')
);
参考URL
Sencha Ext JS6とPhoneGap Buildの連携
PhoneGap Build
前回はSencha Ext JS6とcordovaの連携について書きましたが、今回はSencha Ext JS6とPhoneGap Build（Adobe PhoneGap Build）について試してみたいと思います。
PhoneGap Buildがなにができるかというとリモートビルドで、ローカルの開発環境にいちいちcordovaやPhoneGapの環境を構築しなくても、Webアプリだけ作れれば、WindowsからもMacからもAndroidやiOSのネイティブアプリ構築ができます。単純に環境構築が面倒くさいという点と、昔はiOSアプリに作るならまずMac買ってからということで、こういうサービスの需要があるのだと思います。
環境構築
- 前回の記事で作ったものをそのまま流用します。
- PhoneGap Buildのサービスのアカウントは作成しておいてください。
PhoneGap Buildに連携までの手順
1.app.jsonの編集 プロジェクトルート直下にある、app.jsonファイルを以下のように編集します。
- 編集前
- 編集後
2.local.propertiesの作成 プロジェクトルート直下に、local.propertiesファイルを作成してください。 中身はPhoneGap Buildで作成したユーザとパスを記載。
3.Sencha Cmdでビルド実行
sencha app build remote
※既にPhoneGap Build上にアプリがある場合、無料アカウントだと1つしか作成できないので、ビルド前に削除しておいてください。
4.Web上で確認 以下のようにリモート上でビルドされたものが見えると思います。
まとめ
2回に分けてSencha Ext JS6でハイブリッドアプリ開発について書いてみました。 PhoneGap Buildは作成できるアプリの数に制限はありますが、無料で使用することも可能なのでアカウント作って試してみて頂ければと思います。
Sencha Ext JS6のハイブリッドアプリ（cordova）開発
Sencha Ext JSとハイブリッドアプリ
これまでSenchaでハイブリッドアプリ開発をするときには、Sencha Touchとcordova/PhoneGapを組み合わせてきましたが、Sencha Ext JS6になってデスクトップ用とモバイル用のUIが統合されたので、Sencha Ext JS6とcordovaを組み合わせて動かすところまで試してみました。Xcode7からは、Appleの有料開発者ライセンスがなくてもiPhoneなどの実機で試せるようになったので開発の敷居は下がり、実際に手を動かすモチベーションは上がったかなと思ってます。
環境構築
まず今回試した開発環境は、以下になります。
* Sencha Ext JS6（6.0.1）
* Sencha Cmd（6.0.2.14）
* cordova（5.4.0）
* node.js（5.0.0）
* Java（1.7）
* Xcode（7.1）
実際に試してみた手順
1.適当なディレクトリでSencha Cmdを使いプロジェクト生成
sencha -sdk ~/Library/Sencha/ext-6.0.1 generate app MyApp ./
2.Sencha Cmdを経由してcoedovaコマンドを実行して初期化
sencha cordova init com.mycompany.MyApp MyApp
少し気をつけたほうがいいのは、僕の環境では最初1.8系のJavaを入れていて、1.7でいけるなら1.8でもと思って試したのですが、そのときに以下のようなエラーが出たので。ひとまずは1.7で実行するのが無難です。
また「export JAVA_HOME=/usr/libexec/java_home -v 1.7」とかでJavaのバージョン切り替えてそのまま再実行しようとすると、今度は既にcordovaあるよって感じの以下のエラーがでるので、再実施するときには、一度cordovaディレクトリを削除してから実行してください。
うまくいくと、以下のような感じになります。
3.プロジェクトルートディレクトリ直下に配置されている、「app.json」のbuild部分を編集します。
- 編集前
- 編集後
4.ネイティブ化するためのビルドコマンドをSencha Cmdで実行します。
sencha app build modern
以下のような感じで、SUCCESSが表示されていればOK。
5.エミュレーターの起動
sencha app emulate modern
上記のコマンドを実行するとエミュレーターが起動して、以下のような画面が表示されるはずです。
6.実機で確認 「プロジェクトルート/cordova/platforms/ios」配下に「MyApp.xcodeproj」ファイルが配置されているので、このファイルからXcodeを起動して、実際にiPhoneやiPadなどのデバイス接続してビルドすると実機でも試せるようになります。
まとめ
ここまでいけばあとは、通常のSenchaを使った開発の流れにのってネイティブ開発も進めていけるかと思います。 次回は、PhoneGapのリモートビルドを試す方法を書こうと思います。
PDF.jsの分割リクエスト設定
PDF.jsを使ったサンプルの作成と確認
github
PDF.js
- FireFoxではデフォルトで使用されているjsライブラリ。
- ライブラリの中でpdfデータを変換してcanvasで表示してくれる。
- デフォルトの設定では、最初にPDF情報を取得して、その後は1ページ単位にリクエストを投げてデータを取得している。
- PDFで使用されるフォントも必要なタイミングで動的に取得して使用している。
- HTTPステータスコードは200と206以外をエラーとしてハンドリングしている。
- FireFox以外のブラウザを使用する場合には、compatibility.jsをインクルードする。
確認内容
1ページ単位にデータを取得している部分を1リクエストにできるか確認。
フォントファイルの読込タイミングと設定値の確認
HTTPサーバによって、リクエストの投げ方が変わることを確認
エラーハンドリング
- node.jsでレスポンスを返しているところで、200としている部分を404や500などにしてサーバ再起動。
- PDFJS.getDocument(url) にエラー時の関数を指定することで、エラーオブジェクトを取得することが可能。
- 取得したエラーオブジェクトからHTTPステータスコードを取得してハンドリングするような実装にする。
参考サイト
GitHub - mozilla/pdf.js: PDF Reader in JavaScript
pdf.jsを使いブラウザで見られるPDFスライド表示ツールを作った | Web Scratch
How to catch promise runtime Javascript errors? - Stack Overflow
