kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

Windows Live Spaces から移行してきました。


移行ツール使ったんだけど、コードの断片とかガシガシ落ちてますな。残念な結果でございます。

近況ですが DSL Tools や GAT 2010 / GAX 2010等のVS Extentions系を中心に散策中。

物作りを単純に出来合いツール(要するにVisual Studio)でやってると、なんていうか生産効率とかはどこもかしこも一緒なんすよね。(使いこなしている人を比較すれば:使いこなしていなければ残念でした)

結局の所効率を出そうとすると社内のプロセス全体での改善をかけるのと、局所的なプロセスオプチマイズでチューニングしていくしかないわけで。

TFS とかスクラム、アジャイル等での開発プロセス全体でのオプチマイズは全体に効くんでそっちも重要は重要なんだけど。

いわゆるVisual Studio 2010 っていう「包丁を研ぐ」の段階ですね。

 

包丁を使って作る料理の方は Azure や Sync Framework 等を素材にレシピの検討中です。

ネタばらし的な内容となりますがAzureに代表されるクラウドへの対応にあたって弊社システムとしてはクラウド、オンプレミスのハイブリッド形となる見通しでございます。

Webフロントエンド部の構成としてはオンプレミス側にカリカリにチューニングしたシステムを配置し、トラフィックスパイク等はオンプレミスに連れてきて処理を基本戦略としています。なぜかというとクラウドに発生するコストの懸念であり、弊社の事情としては事例記事にもちらっと出てる通りで顧客特性としてスパイクしたら800倍程度のトラフィックが襲い掛かるわけです。このトラフィックはクラウドにおける主要な課金要素でして、一気に数100倍のコストが発生するのはスパイクを処理した事で売上がそれなりにあっても容認しがたい事でございます。なので固定費で運用されている弊社データセンター側システムで処理する事でコストの平準化効果が非常に高く現れます。

また、事例記事で上がっている通り、弊社のCMSエンジンはかなりのキャッシュモンスターとして実装されており、このキャッシュ等のメカニズムはアクセスが一点に集中すればするほど効率が上がる特性を持ちますのでアクセス頻度の低いページへのリクエストがパラパラくる事でキャッシュに使用しているメモリを食われるよりはスパイク部等のキャッシュがカリカリに効く部分を集めて処理する事でより効率的に動作する事が期待できます。

また、クラウドによるスケールアウト戦略は基本的に否定しています。突発的に800倍の負荷がやってくる所にスケールアウト戦略はそもそもマッチしません、せいぜい数倍のスケールなら事前準備でスケールマージンとしてのマシンを立ち上げておく事はできないでもないですが、数100倍のスケールマージンに相当するシステムを立ち上げておいて予期された(スパイクという名の)商戦が来なかった場合に発生したコストが空振りになるリスクがあります。さらにはシステムをクラウド上で動的にスケールさせる事ができると言っても数十分のラグタイムは絶対に発生し、場合によっては商戦が数分で終了してしまう事もあります。この機会損失リスクも許容しがたい訳です。

結果的に可能なオプションは非常に限られており弊社データセンターに十分にチューニングされたシステムを配備し、平常時の数千倍のスパイクをそこで処理できる様にするしかないという事になります。当然のことながら平常時の稼働効率は要求性能の数千分の1でしかなくても綿密にチューニングされている必要があり、スパイクの規模が大きいほど効率的に動作するキャッシュ等のメカニズムは非常に重要度が高い事になります。

クラウド対応を行う上での基本的な設計方針としてはこんな感じではありますが、これを支えるメカニズムに多くの課題があるのも事実です、クラウドからオンプレミスに処理をスイッチするのはリダイレクトすればいいが誰が引き金を引くのか、数分で数100倍のトラフィックが襲い掛かる所ではログをバッチで分析してなんて手段はそもそも通用しません(バッチがオンプレミス系への切り替えを指示したタイミングですでにコストは発生してしまった後になるでしょう)。Webヘッドノードのスパイク監視で許されるラグタイムは高々数秒しかないのでリアルタイム処理は必須になりますし引き金を引きそこなったら数100倍のコストで沈む計算でかなりセンシティブな実装が要求されるわけです。またクラウドにおけるKVSでのデータアクセスの仕方と、オンプレミスでのデータアクセスの仕方を整合させる必要がありそもそもの PaaSで用意されるストレージとオンプレミスで使っている各種ストレージに対して処理方法やミドルが異なる中で処理内容を整合させるという困難なタスクをこなす必要があります。

いずれも簡単にはいかない困難な要素を抱えておりますが一つづつクリアしていく事でいずれ弊社SaaSがクラウド上で動作するようになりましたという報告ができる様にしたいと思っております。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。