10年前の記事で、「.NETシステムアーキテクチャ改造の経験と教訓」の技術ポイントに対する見解。
【.NETシステムアーキテクチャ改造の経験と教訓】内のCSDN改造に関する技術ポイントは以下の通り：
- データ層：SQL Serverデータベースとストアドプロシージャを放棄し、すべてLinuxプラットフォーム上のMySQLデータベースに移行。
- キャッシュ：.NET自身のキャッシュ機構に依存せず、Linuxプラットフォーム上にデプロイされた分散型Redisに移行。
- サービス間の呼び出し：.NET独自のプロトコルを避け、RestfulなHTTP Web API呼び出しに変更。
- 静的リソース要求：IISで処理せず、Linuxプラットフォーム上のNginxに分離。
- 読み取りが必要なファイルシステム：Linuxプラットフォーム上の分散ファイルシステムにアクセスするよう変更。
- .NETコードをデプロイするWindowsサーバーをLVSの背後に配置し、LVSで負荷分散とフェイルオーバーを実施。
1. データベースはSqlServerかMysqlか
Webプログラムとして、Web側はボトルネックにならず、ボトルネックは常にデータ側にある。通常の論理では、.NETの実行速度はPHPより速い。なぜなら.NETはコンパイル型で、PHPはインタプリタ型だからだ。しかし現在多くの大規模サイトはPHPで構築されている。主な理由は、PHPには既存のソリューションが多いからだ。
システムに問題が発生した場合、それは言語の問題ではなく、アーキテクチャの問題、あるいはアーキテクトの問題である。Webサービスにおいて、ほとんどの場合ボトルネックはデータベースにある。sqlserverデータベースのライセンス費用が高いという意見もあるが、qinfoで大衆点評の講演を探してみてほしい。彼らはasp.netとmysqlデータベースを使っている。本質的にSqlServerとMySQLはどちらも構造化データベースであり、開発者にとって大きな違いはない。データベースの拡張性は大まかに言って、1) データベースの読み書き分離、2) 業務水平分割、3) 大テーブルの垂直分割である。その他は細かい実装に過ぎない。
2. キャッシュは自身のキャッシュか分散キャッシュか
CSDNはキャッシュをRedisに移行したが、これは.NET自身のキャッシュ機構の問題ではないと思う。分散キャッシュを行う場合、MemcacheでもRedisでも、間にマシンが介在するため、Webサーバーのキャッシュより遅くなるのは確実だ。業務量が小さければ、キャッシュサーバーをWeb自身のキャッシュ機構の代わりに使うのは割に合わない。システムのアクセス量が一定レベルに達し、自身のキャッシュ機構ではシステム要件を満たせなくなった場合、キャッシュサーバーに切り替える必要がある。もちろん、Windowsサーバーをキャッシュサーバーとして使う人はいないだろう。.NETでもJavaでもPHPでも、memcached/Redisを使うときにパフォーマンスに違いがあるだろうか。CSDNが最初に改版したのはブログシステムで、博客園のブログシステムも同じものを使っていたが、今では修正が加えられて原型をとどめていない。しかし、当時のCSDNのブログがあれだけのユーザー数で、.NET自身のキャッシュでどうやって持ちこたえたのか想像しがたい。博客園の雲路の記事を見れば、博客園がmemcachedキャッシュを使っていることがわかる。
私の理解では、キャッシュはユーザー数が少ないうちはWeb自身のキャッシュ機構を使い、一定規模に達して自身のキャッシュ機構が大量のデータキャッシュに対応できなくなったら、分散キャッシュコンポーネントに切り替えるべきだ。そして従うべき原則は、データをよりユーザーに近づけることだ。現在多くのインターネットサービスでは、memcachedや類似のkey-valueデータベースを使ってすべてのデータをキャッシュに置き、mysqlなどの構造化データベースはデータベースのバックアップとしてのみ使い、キャッシュが無効になった場合などにのみデータベースからデータを読み取る。
3. システムプロトコルの選択
マイクロソフトはプロトコルに独自の要素を追加するのが好きで、その場合自社のソリューションしか使えない。全面マイクロソフト製品を選択するなら非常に便利だが、非マイクロソフト製品を使う必要が出たときには困る。Webサービスでは、主にwebserviceやwcfのhttpサービスがある。webserviceは公開された標準規格であり、XML形式のプロトコルである。
Web Serviceは新しい技術であり、異なるマシン上で動作する異なるアプリケーションが、追加の専用サードパーティソフトウェアやハードウェアを介さずにデータを交換したり統合したりできる。Web Service仕様に従って実装されたアプリケーション間では、使用する言語、プラットフォーム、内部プロトコルに関係なくデータ交換が可能である。Web Serviceは自己記述的で自己完結型の利用可能なネットワークモジュールであり、具体的なビジネス機能を実行できる。また、Web ServiceはXMLやHTTPなどの一般的な産業標準や既存の技術に基づいているため、デプロイも容易である。Web Serviceはアプリケーションインターフェースのコストを削減する。Web Serviceは、企業全体や複数の組織間でのビジネスプロセス統合のための汎用メカニズムを提供する。
Web転送において、JSONはXML形式より簡潔で、JavaScriptネイティブでサポートされ、サードパーティのサポートも多いため、キャリアとしてJSONを選ぶ方がXMLより良い。Restfulは私にとってはプロトコルというよりも、データアクセスのスタイルであり、URLリクエストをより明確にするものだ。したがって、WebシステムでAPIを作るなら、RestfulスタイルのAPIとJSONをキャリアとして使う方が好ましい。すべてマイクロソフト製品で統一するなら、WCF（マイクロソフト製）が最良の選択だと思う。
4. ファイルシステムの選択
ファイルサーバーをLinuxに置くのはWindowsより良い。最低でもLinuxはファイルの断片化に対処する必要がない。まあ、ファイルサービスをやったことがないので、良し悪しは言えない。
5. 静的リソース要求はIISか、それとも分離するか
IISは静的ファイルしか処理できない。例えば.aspxのような動的ファイルにアクセスすると、IISはaspnet_isapiにリクエストを渡し、結果をIISに返す。静的ファイル処理において、NginxはIISより優位性がある。静的ファイルを処理するときによくやるのは、jsやcssファイルを結合・圧縮し、一つまたは複数の独立したサブドメインを画像サーバーとして用意することだ。フロントエンドの待機時間を減らすためだ。あるいは画像サービスを又拍や七牛などのサービスに任せる。以前又拍を調べたことがあるが、RESTとフォームAPIのインターフェースを提供しており、簡単に統合できる。CDNアクセラレーションも提供しており、自分で静的ファイルサーバーを構築するより安上がりだ。
6. 負荷分散...
Webサーバーが不足した場合、Webサーバーに負荷分散を導入する必要がある。もちろん負荷分散の方法はたくさんある。私も導入したことがないのでよく言えないが、単一のWebサーバーで業務要件に対応できなくなった場合、負荷分散は必須である。
まとめ
以上の6点のうち、第2点（著者のシステム理解が不十分だと思う点）を除けば、他の点は支持する。システムに問題が生じた場合、それは言語の問題ではなく、アーキテクチャの問題である。もちろんこれは私個人の考えであり、私の認識がすべて間違っている可能性もある。
著者：張巍 出典：http://beixiu.net/