スマートフォン

BlackBerryが「BlackBerry Application Center」を立ち上げるらしい、と今朝のニュースで発見。Appleの「App Store」に対抗しての対応と思われる。スマートフォンユーザにとって利用できるソフトウェアが手軽に入手できる事は喜ばしいことである。　一方ソフトウェア開発をビジネスにしている立場から見ると、スマートフォン向けのソフトウェア開発は大きな夢を感じる。　前述のとおりネットを通して簡単に販売できるチャネルが確立しつつあるので、自社で開発したソフトウェアが世界中のユーザに利用していただける可能性があるためだ。弊社でもiPhone開発に注力しているが、早期に世界中で利用できるソフトウェアをリリースしたいと考える。　今後は、モバイル端末からクラウドのサービスを利用するのがトレンドになっていく可能性が高いが、利用可能なソフトウェアの絶対数が不足している状況なので、その領域でのソフトウェア開発の必要性を強く感じている。　

本当に統合して大丈夫？

ここ数年サーバー統合が進んでいる。　スケールアウトでむやみに増加したサーバー群を管理する事が容易ではなく、運用コストも馬鹿にならないし、無駄なリソースがもったいないなど、問題が多いからだ。　そこで、統合、という動きは正しいと思う。だが、統合すれば全ての問題が解決されて皆ハッピーといくのだろうか？　多くの問題は解決されるだろうが、新たに背負い込む問題もある。　”統合＝集中”という構図では、今までは、どこかのサーバーが障害を起こしても、他のサーバーがなんとかしてくれていたはずである。　当然、統合したサーバーも冗長構成を組むなど、ＨＡ対応は必須であり、システムダウンしない対処が必要。　しかし、この集中化が厄介な面もある。　今までのスケールアウトな構成では、いい加減さを許容してくれていたのではないだろうか。　稼動するシステムのリソース計算など、”多めに用意すれば大丈夫だろう”といった感じで。だが集中したシステムでは、このいい加減さの許容が減ってくる。　ある意味メインフレームでのシステム運用に似てくると思う。　メインフレームは、”ほとんどダウンしません”とその可用性が売りであるが、本番業務で稼動しているシステムは、ダウンしないように最適化されているから可用性が高いのだ。　本番運用前のテスト稼動時の最適化前にシステムは結構ダウンする（こともある）。　安定稼動する為には、システムリソースの利用状況などを十分に試算した上で、本番業務運用に耐えうる”設計”が重要。　ＩＡサーバによる統合においても運用管理ツールやモニターリングツールなどで、最適化を図ることが可能である。よって、統合して”集中”したシステムが最適な状況にあるかどうかを見極める目が非常に重要であり、むやみに統合すると新たなリスクが発生する事を認識する必要がある。