kagamihogeの日記

kagamihogeの日記です。

Microsoft Tech-Ed 2008 Yokohama - 8/29(金)

Microsoft Tech・Ed Japan 2011 ホーム の 4 日目、最終日。

以下、トークセッションの内容について&毎度のお断り文句。自分の所感・意見と発表者の発言やプレゼン資料の内容ごちゃ混ぜに書くので、読みにくい点が多々あると思います。日本語崩壊してる部分も多々です。自分用の備忘録的な意味合いの強いエントリなので、そのあたりの読みにくさについてはご容赦願います。

クラウド コンピューティングに対応する次世代アーキテクチャ設計法

REST と SOAP の比較という切り口から、これからの Web アプリケーション開発のアーキテクチャ―特に分散(ここではクラウドという単語を使っているが)を意識した場合―は、どうなっていくのか? どうあるべきか? といった辺りの話。抽象度の高い話だったので、下記の記述には間違いや、俺の解釈ミスが多々含まれている可能性が高いです。そのため、そのことに注意して読んで下さい。

まず、REST と SOAP ベースの違いの比較。ここの話は RESTful Webサービス の最初の方でも議論されてたかな。ちなみに、俺はまだ最初らへんしか読んでません…… REST は、uri そのものがリソースを表現しているのに対し、SOPA は HTTP POST そのものがメソッド呼び出しに近い考え方であり、エンティティボディ内にデータが入っている、とかなんとか。重要なのは、どちらも uri をベースにしている。ただし、その利用方法に関してはかなりの違いがある、という点を認識するのが重要である、とかなんとか。

クラウドコンピューティングを考える上で、REST は重要なキーワードになる、という話をしていた。クラウドコンピューティングとは、いわゆる Web Oriented Architecture(WOA:うぉあ と発言していた) とかリソース指向とか呼ばれる分野のこと。REST は既存技術の組み合わせで出来ているので、(Web の世界では google などで)スケールアウトが可能なことも実証済みなため、パフォーマンスの点からも有利な点がある、と述べていた。

SOAP vs REST の話。このため、登壇者は以下のような予測を話していた。SOAP の使われる分野はイントラネットや B2B といった閉じた環境での利用に限定されていき、REST はB2C、SaaS という広い Web の分野で使われていくのではないか、と。

SOAP はインタフェース指向。呼び出しのインタフェースが決まってしまうため、呼び出しの仕方と実装が密に結合してしまう欠点がある。

REST はリソース指向。1 サービスが CRUD の 4 操作に絞られるため、提供したい何かを分割し、結合するなんたらかんたら。SOPA のように複雑なインタフェースを一つ提供する、といようなことをしなくて済む、とかなんとか。

ごめん、うまくまとめて説明できんわw

REST のトランザクションは、トランザクションに ID を付けてしまえばよい。リソース指向で考える場合、物理実体に縛られる必要は無い、ということ。つまり、なんにでも ID を付けて一意識別すればいい、ということらしい。

REST の開発方法についての話。応答形式は、HTTP のステータスコード、データの表現形式は plain text や JSON(Ajax 的なものならこっち)や XML 的なものを使用する。

トランザクション処理(Transaction Resource Pattern)の話。トランザクションを kick する仮想的なリソースを定義し、その uri に対して呼び出しをする、といった感じの設計パターンが既に存在する、らしい。MS では、仮想的なコンテナのようなリソースを定義し、そこに対してトランザクションを要求する、というような考え方をもっていた。その考え方はこれから変えていく、とかなんか。それが重要なんだ、といっていたけど今ひとつ意味が良くわからなかった。

REST は UI 抽象化層である、という話。REST のリソースがフロントエンドになり、そのバックエンドに、Logic-Entity-(永続化)データ、というものが存在するイメージ。いわゆる、機能要求というかユースケースというか、システムの一つの切り口を REST リソースで表現する感覚。

REST のクラスの実装戦略の話。クラスの粒度や、OOP の考え方とどうマッピングしていくか? 登壇者は、REST のインタフェースの定義の考え方と、OOP の考え方は別モノなので、O/R マッピングのような考え方でマッピングすることになるだろう、と考えている、と話していた。まーつまるところドメインクラス側は粒度の細かさをどーするか、が問題になるってことですかね? あとは、実際にフロントに見える REST リソースのインタフェースがどうしたら使いやすいものに設計出来るのかが肝要、って感じですかね?

SOA から WOA へ。図で、計算機のハードウェア的な進化とソフトウェアの進化、設計パラダイムの変化を整理していたが、コンピュータサイエンスの歴史の観点からも非常に興味深い議論だったと思う。

仮想化の話。従来は、既存システムを新しいマシンで動かす、的なところがあったが、スケールアウトを前提した仮想化、という考え方へ変わっていくだろう、と。並列分散処理の拡大が進むだろう、とかなんとか。

開発パラダイムとしては、OO + 関数型などが重要になっていくだろう、と。複数のパラダイムを組み合わせ・取り入れていくスタイルが重要になっていくのではないか、と。

そのために、登壇者は「縦と横の構造の原則」という思想を提唱していた。お客様の要求にはさまざまなレベル・種類というものがあり、それらに対応・実現するには、各層で「実装」を行う。で、各層での要求の拡張や変更というものに対しては、各層でのスケールアウト・ポリモーフィズム・mixin,trait のような形での振る舞いの追加、による柔軟な振る舞いの切り替えを行う、みたいなムニャムニャ。ごめん、理解出来てるとも思わないし、まとめられてるとは思わないw

Constratint Programming の話。Eiffel の制約みたいな感じの話かな? って印象を受けた。

SQL Server 2005 パフォーマンス チューニング ベスト プラクティス

俺は SQL Server 2005 のみならず DB について詳しいと呼べるレベルではないです。そのため、下記のレポートには、間違いや俺の解釈ミスが多々含まれている可能性がある点について注意してください。

SQL Server 2005 パフォーマンス チューニングに関しては、インサイドMS SQL SERVER 2005クエリチューニング&最適化編 (マイクロソフト公式解説書)インサイドMicrosoft SQL Server 2005 ストレージエンジン編 (マイクロソフト公式解説書) といった書籍が参考になるそうです。

共有リソースの利用について。SQL Server のパフォーマンスチューニングを考える際、メモリー、プロセッサー、ディスクなどのストレージが、どういうった操作をしたときどのような動作をするのか把握するのが肝要、と述べていた。メモリのキャッシュのされ方とか、windows OS と SQL Server の関係とか、チェックポイントの一括更新の動作、とか。

ハードウェアについて。仮想アドレス空間の選択の話をしていた。32bit 方式では 4GB が上限、AWE により 64GB まで拡張可能だが、これを利用できるオブジェクトはデータキャッシュのみなことに注意、など。NUMA 型ハードウェア(Non Uniform Memory Access)てなもんも一つの重要なキーワードらしい。よく知らない分野です。

プロセッサーについて。いまんとこは IA32 / x64 が主流らしく、Itanium 2 (あいたにあん、と発音してい)は大規模・信頼性重視の場所で使われいてる、と話していた。ハイパースレッド機能は、SQL Server 2005,2008 ではあまり推奨されない、等の情報も。

ディスク・ストレージについて。以前は SCSI が主流だった。最近は SAS ドライブ、大容量 SATA ドライブが登場してきたとかなんとか。この辺のドライブの使い方についてのノウハウの話をしていた。RAID 1 + 0 を 4 つ用意、てのが最低限確保して欲しいレベルなんだとか。

SQL Server 2005 の新規導入について。SQL Server 2005 を念頭に置いて使える魅力とは? DB ミラーリング、データパーティショニング、楽観的同時実行制御、インデックスの動的再構築。ただまぁ、リソースは結構食うのでハードウェアの選定は慎重に行うべし、とか。

旧バージョンからの移行。アプリはそのままで 2000 -> 2005 に移行したい場合、ウィザードは用意されてはいるものの、2000 -> 2005 でアーキテクチャ色々変更されてるんで、アプリの動きに影響出る場合がある。そのため、互換性テストの計画・実行をしっかりするのが大事、と。

アプリケーションの変更なしで利用可能な SQL Server 2005 の機能。x64 環境への移行、ただしメモリ上限が変わるため、データキャッシュまわりで問題が起こる可能性有。DB ミラーリングの利用。READ_COMMITED_SNAPSHOT によるブロッキングの回避、 NUMA 対応ハードウェアの利用。

SQL Server 2000 では非公開なコマンド・関数が、SQL Server 2005 では DMV(これなんだろ?)として公開されている。

現行システムのボトルネックの探し方 3 つのポイント。内部の待ち事象からの考察、データベース I/O 負荷の把握、パフォーマンスカウンターの値。

メモリに関する注意点。32bit と 64bit のメモリーアロケーション方法の違いを理解する。そこにキャッシュされるオブジェクトの種類と性質を知る。クエリー実行時に必要なメモリーの構造も重要。

プロシージャキャッシュの肥大化。32bit と 64bit 環境下では、アドレス空間の上限値拡大により、色々な種類のキャッシュが、食いつぶし合い・肥大化をはじめる。そのため、キャッシュの利用のされ方を視野にいれたクエリ設計が重要になる。だが、アプリケーションの改修が必要になってしまうケースもあるので注意しなければならない。チューニングの方針としては、良く使われるクエリを見つけ出して、そこを取っ掛かりにして優先的につぶしていく、など。

待ち事象・ディスク I/O 負荷の分析。様々なパラメータを見て、どんな現象が起きるかを把握するのが重要。

SQL Server の移行時の確認のポイント。SQL Server 6.5 は Sybase をベースに作られているので、2000,2005 と構造がぜんぜん違うのでかなり厄介。SQL Server 7.0 / 2000 - よくわかんなかったので割愛。SQL Server 2005 / 2008 - 統計情報の管理方法が異なるのが最大のポイント。

導入事例。IA32 + AWE -> IA64 にした話。32bit から 64bit にただ単純に置き換えたからつって、必ずしもパフォーマンス良くなるわけではないんだね……無論、ケースバイケースなところもあるし、移行によって処理能力良くなってる部分もあるんだけど。負荷のかかる場所が変化したり、リソースが有効に使われるようになった部分が出てきたりするんだなー、といった印象を受けた。

2000 -> 2005 移行時に発生したインテント排他ロックが多発した問題の考察。統計情報ってヤツが、2005 移行時に更新されてないために起きた問題らしい。このため、SQL Server が最適な実行プランが出来なくなる、なんてケースだったらしい。

インデックスの再構築が必要な利用。テーブル内フラグメンテーションの解消、出来れば定期的に再編成してやるのが良い、とのこと。

統計情報の更新について。統計情報は、インデックスキーの分布状況を持ってて、オプティマイザはこいつを参照してる。で、こいつがインデックスの参照方式を切り替えるんで、実態と分布状況の乖離があると、オプティマイザがヘンテコな動作をすることがある。

AUTO_UPDATE_STATISTIC は既定 TRUE 。登壇者は、これは確かに便利と前置きした上で、頼りすぎは危険なのではないか、と述べていた。DBA が判断して、明示的な統計情報の更新が望ましいのではないか、と。

OLTP パフォーマンスについて。負荷の高いテーブルのジョイン数や、更新頻度の高いテーブル上のインデックスの推奨値の一例を示したり、I/O 負荷の推奨値の一例、ブロッキングの比率例などを示していた。

System Center Virtual Machine Manager を利用した Windows Server 2008 Hyper-V 管理のベストプラクティス

登壇者の昨日?のセッションでは、仮想環境の運用の理想的な話をした。また、初日では Hyper-V の深いセッションもあった。本セッションでは、その辺の製品を使用した際の運用管理・使い方について。

俺は運用管理・インフラ周りはサッパリなので、下記の文章にはヘンテコな記述がある可能性が高い点に注意してください。

System Center Virtual Machine Manager(長いので以下 SCVMM) の日本語の情報は少ないらしい。今のところ、登壇者の blog http://blogs.technet.com/osamut/ が最も詳しい、などと言われているらしい。本セッションは System Center Virtual Machine Manager 2008、まだβ版なので、画面とかは色々変わるところもありますよ、との前置きが。

Hyper-V は Windows Server 2008 に標準で搭載されるサーバー仮想化機能。SCVMM は、そうした複数の仮想環境を管理するための製品。SCVMM 2008 から Hyper-V, VMWare ESX, Virtual Server に対応する。

SCVMM の管理は、GUI の管理コンソールと CUIPowerShell コマンドが用意されている、といった感じの話だったかな? セルフサービスポータル、というエンドユーザーに仮想管理環境の管理権限をある一定の範囲で委譲できるものも存在する。

ホスト利用時の選択について。管理 OS である Windows Server 2008 インストール時に Server Core インストールがオススメ、とのこと。仮想環境を前提にする場合、最小構成でインストールできるので色々利点がある、と。

ライブラリについて。これは、共有フォルダのようなもの。サーバーのテンプレートとなる VHD や ISO イメージやアプリを置いておいて、これを配布することで仮想マシンの展開を行う。オフラインパッチング。ライブラリは、実態は共有フォルダのようなものなので、ファイルが陳腐化していっていまう。その更新とかに System Center Configuration Manager とかいうツールを使うらしい。

登壇者は、物理/仮想環境の透過性がすすむと、逆に、どの仮想マシンがどの物理マシンがどこで動いているの? という状況になるのでは? と話していた。これは、柔軟な運用が可能になるという利点も大きいが、「見えない化」の恐れもあるので、管理・レポート機能の充実が必須になるのでは、と述べていた。あと、仮想環境を意識したネーミングルールも重要、みたいな話もあった。その辺のレポート・監視ツールに System Center Operations Manager 2007(OpsMgr) という製品がある、とかなんとか。

チェックポイントの活用について。Hyper-V のスナップショット機能を利用している代物。何かの設定終わった段階で取っておいたり、エラーが発生したときの状態を取っておく、とかに使うらしい。また、チェックポイントはバックアップではないことを理解するのが大事、と。バックアップは障害対策など、チェックポイントは柔軟な運用に使うため、という性質の違いがある。用途に応じた使い分けが重要、と話していた。

VMWare 環境の移行。P2V とか V2V とかいう方法があるらしい。

Windows フォーム開発者に捧ぐ!WPF への移行 - ビジネス アプリケーションにもユーザー エクスペリエンスを -

WPF の実演と VB.NET のコード示しながらのデモ多めセッションでした。関心高い分野なせいか、心なし観衆も多めに感じました。

WPF への移行を薦める理由を 3 つ上げていた。1. GDI, GDI+ の限界。windows が出来た頃から存在してる代物なので、そろそろ限界がきている。2. MS 自身が Windows フォームへの投資を減らしつつある。3. ビジネスアプリにもリッチな UI が求められている。

WPF への移行にあたって。UI 部分を、旧資産である Windwos Form から WPF へ機械的コンバートが出来ない点に注意。ただし、ビジネスロジックの利用は出来る。

ビジネスアプリケーションに WPF そもそも必要あるの? 理由としては、高速なレンダリング・高い表現力・UI とロジックの分離、などを挙げていた。

Visual StudioExpression Blend の使い分け。ここの使い分けは、ルールを決めて運用しないことには、やはり厄介なようだ。Flex の開発も、こういう感じに UI の開発は別ツール、な風になる or したほうが良いんだろうか。

WPF やるには、XAML は避けて通れない道。

デモ見てる限りでは、WPF は Windows アプリお手軽に作る方法の一つとしては中々良いモノになりそうな予感はする。そして、Blend は相変わらず Adobe 製品のパクりに見えてしまうw

Windows フォームで WPFコンポーネントを動かす、WPF で Windows フォームのコンポーネントを動かす、なんてデモをしていた。こういう相互運用の部分って、どんだけまともに動くか、ってのはまぁあると思うんだけど……相互運用性の確保を意識してくれてる点は良いですな。

デモ見てて思ったのは、VB/VC, ASP.NET の流れも汲んでるせいか、XAML とコードビハインドの分離が最初っから出来てるのが良いなぁ、と。Flex は若干ここが弱いんだよね…… yui-frameworks があるとはいえ、MXML と ActionScript の分離・データバインディングがもっとカンタンに出来ると良いんだけどなぁ、等と思うのです。Flex は、片方向バインディングはともかく、双方向がちょっとメンドウなのよね。業務アプリだと、デフォで双方向バインディングにしちゃった方が、使い勝手良い、ってケースが結構あるんじゃなかろうか?

コンポーネントのドラッグ&ドロップ。XAML だけではムリで、ちょっと C# なり VB なりでコード書く必要がある。ただ移動させるだけとかならまぁいいんだけどね。ここは Flex でもそこそこ大変なんだけど、WPF でもそこそこ大変なんだねぇ。

非同期処理。Dispatcher.Invoke と BackgroundWorker。

印刷。XPS と GDI。

デモが遊び心ありすぎてすげぇw と感じたセッションでした。他のセッションは軒並みカタックルしい中のに良くやるなぁ、と感心してしまった。

Internet Explorer 8 最新ベータ ビルドにみる新機能と変更点

すいません、疲労も手伝って「ホー IE 8 ってそんな感じなんだぁ」ってボーと見てたのでレポートはナシです。まぁ、諸機能に関しては公式サイトや、解説記事見たほうがわかりやすいだろうしね。

解説の仕方は結構上手いかな、と感じた。ブラウザの使い方とか RSS とかの便利機能を、あんまりコンピュータ使わないヒト向けに説明するやり方の参考になりそうな気がしました。