開発のあいまに

Microsoft公式の開発支援ドキュメントメモ

Microsoft Docs

ASP.NET Core チュートリアル

Visual Studio 入門

業務システムで使うDBの選択基準の定石

365日24時間止められないシステムならORACLEを選択する。

平日9:00～21:00頃まで使われ、それ以外の時間帯をシステムメンテナンスに使えるなら、ライセンス料がOracleの半分で済み、開発難易度も低いSQLServerを選択する。

CPU使用率が100%になるようなシステム異常が発生した場合、SQLServerだと、SQLクエリアナライザなど、DB分析ツールの負荷が高い為、DBへ接続している全ての処理を一旦停止し、DB負荷を下げてからじゃないと、DBサーバーの改善に着手できない。

しかし、ORACLEではCPU使用率が100%になっていても、ADDMなどのDB分析ツールはサクサク動くので、リアルタイムにシステム異常を解消していける。この耐障害性では、まだまだ、Oracleに一日の長がある。

ただ、SQLServerでも、夜間や休日にメンテナンス処理をきちんと実施していれば、業務時間中にCPU使用率が100%になるようなシステム異常が発生する事はまず無い。

SQLServer、Oracle、どちらのEnterprise版にもテーブルのpage圧縮機能があり、100TBクラスのDBなら、データベースサイズが、どのDBにするかの判断基準にはならない。

Windows7 にDBを構築する場合、シャドウコピーを無効にしないと、処理性能が極端に低下する

Windows7 に SQLServer 2008/2012 をインストールして、DBサーバーとして利用していますが、DBサイズが50GBを超えた辺りから、定期的にDBの処理性能が10分の1に低下する現象が、発生するようになりました。

DBサイズが増加するにつれ、その頻度が多くなり、継続時間も長くなってきたので、本格的に調査した結果、Windows7のシャドウコピーが原因だと分りました。

シャドウコピーを無効にする事で、処理性能が極端に低下する事は無くなり、Windows7 でも 社内DBサーバーとして十分活用できています。

シャドウコピーを無効化する方法は、こちらを参考にして下さい。
http://www.se-support.com/clientpc/volumeshadow.html

シャドウコピーが無効になっている状態はこちら。

SQLServerで、IISからのDB処理だけが遅い場合は、ストアド、ファンクションをリコンパイルする

テラバイトクラスのDBシステムを扱っていると、データ量が増えるたびに、特定のSQLが極端に遅くなることがあります。

その時に、遅くなったSQLの実行プランを確認すると、インデックススキャン（Index seek）のコストが跳ね上がり、SQL全体のコストの100%近くを、インデックススキャンが占めるように変化しています。

インデックススキャンのコストは、SQL全体で20%未満になっているのが、妥当な値です。

極端に遅くなっている、もしくは、コストが高くなっているSQLは、SQLServerのチューニングアドバイザーにかけると、インデックスと統計情報が抽出されるので、それを適用する事で解決できます。
※SQLが遅くなっているサーバーで、チューニングアドバイザーを実行せず、別のサーバーでチューングアドバイザーにそのSQLをかけると、必要なインデックスと統計情報が抽出されない事があるので、そこは注意が必要です。

テラバイトクラスのDBシステムを1年以上運用していて、今回初めて、必要なインデックスと統計情報を追加しても、IISからのDB処理だけ処理性能が改善しない、という現象に遭遇しました。
Management Studioからだと、遅くなっているSQLの実行プランは改善され、実行時間も1秒程度なのに対し、WEBサイトからそのSQLを実行すると、5分たっても結果が返って来ませんでした。

【環境】
WEBサーバー：Windows Server 2008 R2 SP1
DBサーバー：Windows Server 2008 R2 SP1、SQLServer 2008 R2 SP2 CU3
WEBサイトは.Net4.0で構築

色々試した結果、WEBサイトから実行した場合のみ遅い現象が発生したら、ストアドのリコンパイルが有効だという事が分かりました。ユーザー定義関数を利用している場合は、関数のリコンパイルも必要です。

ストアドに実行プランをキャッシュする、こちらのアーキテクチャにバグがあって、IIS側からアクセスされた場合に、古い実行プランを使い続けていたのが原因でした。
http://msdn.microsoft.com/ja-jp/library/ms181055(v=sql.105).aspx
http://msdn.microsoft.com/ja-jp/library/ms191007(v=sql.105).aspx

そういえば、SQLServerはIISのキャッシュを、別扱いするという技術資料を、以前どこかで読んだ気がします。

毎日のように、インデックスと統計情報を追加しているシステムなので、再発防止として、インデックスと統計情報を追加する頻度の高いテーブル、ストアド、ユーザー定義関数は全て、日次で夜間に、sp_recompile を実行するようにしました。
http://msdn.microsoft.com/ja-jp/library/ms181647.aspx

 

【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL

 

本番環境へリリースする際の基本手順

１、本番リリース前々日から前日にかけて、リリースのリハーサルを繰り返す。

　・本番ＤＢサーバーから最新ＤＢダンプを取得し、ステージング（総合試験環境）へ展開。
　・本番リリース担当者が、ステージング環境へのリリースと動作確認を繰り返し、習熟度を高める。
　・リリースタイムテーブルを作成し、関係者へのアナウンスと承認を得る。
　・リリース時のチェック項目を、一覧で作成する。

2、本番稼働中にバックアップ可能なものは、本番稼働中にリリース前の状態をバックアップしておく。

　・本運用中のモジュールを、フォルダ毎バックアップフォルダへコピーする。
　・バックアックしたフォルダには、年月日(YYYYMMDD)を付加しておきます。

3、本番稼働中に展開モジュールを準備する。

　バックアックしたフォルダを複製し、リリースモジュールで上書きする事で、リリース実施時には
　フォルダ入れ替えで済むようにしておく事で、リリース実施作業時間を短縮する。

4、本番環境の使用を禁止する。

　・全クライアントＰＣ
　・サーバ

5、本番リリース直前のＤＢをバックアップする。 

　・ＤＢの最新ダンプを出力し、バックアップフォルダへコピー。
　・ダンプファイルには、年月日時分(YYYYMMDDHHMM)を付加しておきます。

6、展開モジュールを本番リリース。

　・全クライアントＰＣへ展開モジュールをリリース。
　・DBサーバへ展開モジュールをリリース。
　・WEBサーバへ展開モジュールをリリース。
  ・キャッシュファイルを全て削除。
　・WEBサーバを再起動。　

7、リリース内容再確認。

　リリース時のチェック項目を元に、作業漏れが起きていないかチェックする。

8、リリース後、本番動作確認。

　ログイン、画面遷移レベルで、本番環境の動作確認。

9、本番環境が復帰した事を関係者へ周知。

　・開発責任者と開発スタッフ

　・業務責任者と業務スタッフ

10、本番環境を運用試験環境へ展開。

　本番リリース後、安定稼働が確認できたら、本番環境を運用試験環境へ展開する。
　必要であれば、総合試験環境、結合試験環境へも展開する。

 

究極の開発ステップ

品質を落とさずに、究極の開発速度を実現する、開発ステップ。

1、要件を一覧化し、どの要件をどのフェーズで実装するか、明確にする。

2、各要件の仕様詰めは、サンプル画面と各アクションのみ記述した画面仕様書と、画面遷移のみのスケルトンアプリによるデモを中心に、口頭による説明で仕様を詰める。

3、要件定義の段階から、ルートプログラムを作成し始め、要件確定後はそのプログラムを横展開する形で実装を進める。

4、各設計は、テーブル設計書など、データのIN/OUTの要となるドキュメントのみ作成する。

5、コーディングをする前に、シナリオテスト仕様書を作成し、仕様の不備を検定する。

6、コードは基本的に日本語で記述し、コメントをほとんど記述しなくても、読み易いコードにする。

7、テスト仕様書は、シナリオのみ作成する。

8、シナリオテスト以外は、要件定義書や各仕様書を基に、赤ペンでテストを実施して行く。

ソフトウェア開発プロジェクトが火を噴く原因と対処のパターン

ソフトウェア開発プロジェクが火を噴くパターンは、自分の経験から判断する限り、３つに分ける事ができる。

１、リリースまでに要件を満たせていない。
２、技術課題をクリアできていない。
３、品質に問題がある。

自分が考える原因と、解決方法を以下に列挙します。

　

１、リリースまでに要件を満たせていない。

【原因】
要件に対する見積が甘かった事で、納期までにソフトウェアが完成しない事が、開発の後半を過ぎた辺りに発覚する事で発生します。

【対処】
・要件に無茶がある場合は、フェーズを切って、初期リリースまでに必須な要件、初期リリースではなくても構わない要件、本当は無くても構わない仕様を分けてリストアップ。
・フェーズを分ける事をクライアントに説明し、初期リリース時に必須だと認識している機能に齟齬が無いか、本当は不要な機能はどれか、クライアントに事情を説明した上で再度認識を合わせ、各フェーズの実装内容とリリース時期を調整する。
・クライアントへ誠実に事情を説明し、クライアントにとっての損害を最小限に抑える為に、対応可能な選択肢の中で、今後プロジェクトをどう進めれば良いか、建設的な議論を行う必要があります。

　

２、技術課題をクリアできていない。

【原因】
技術課題をクリアできない事が開発後半で明らかになるのは、ソフトウェア開発プロジェクトにとって最も致命的です。その為、要件定義段階で最も優秀な人材を投入し、見積の範囲内で実現可能な技術方式を決め、プロジェクトが開始されたら早々にプロトタイプの開発を始める事が重要ですが、これを怠ると本トラブルが発生します。

【対処】
・プロジェクトに参加しているメンバーの中で、最も優秀な人員を投入し、引き継ぎを行った上で、改めて実現可能な技術方式とプロトタイプの作成をやり直します。
・プロジェクトのメンバーでは解決不能と判断される場合は、外部の優秀な人材を投入します。
・クライアントへ誠実に事情を説明し、クライアントにとっての損害を最小限に抑える為に、対応可能な選択肢の中で、今後プロジェクトをどう進めれば良いか、建設的な議論を行う必要があります。

　

３、品質に問題がある。

【原因】
>要となる設計書が無かったりメンテナンスされてなく、必須のテスト仕様書を作成せずに開発を進める事で、納品までに最低限のテストが行われず、納品後に品質の問題が発生します。

【対処】
・要となる設計書をちゃんとメンテナンスし、それに基づいたテスト仕様書を用意します。
・何をインプットすると、どういうアプトプットが返って来るのか、精度の高いシナリオテスト仕様を作成し、テストを実施します。
・各入力欄に対する限界値分析を行い、限界値テストを実施します。

　

超短期開発を実現する為の基本ステップ

１、要件定義書には、サンプル画面と各アクションのみ記述し、画面遷移のみのスケルトンアプリのデモと、口頭による説明で、仕様を詰める。

２、設計は、テーブル設計書など、データのIN/OUTの要になるドキュメントのみ作成する。

３、コーディングをする前に、シナリオテスト仕様書を作成し、仕様の不備を検定する。

４、テスト仕様書は、シナリオのみ作成する。

５、コードは基本的に日本語で記述し、コメントをほとんど記述しなくても、読み易いコードにする。

６、シナリオテスト以外は、要件定義書や各仕様書を基に、赤ペンでテストを実施して行く。