ベンダーロックイン排除のためにオープンという議論 - Nothing ventured, nothing gained.
自治体などの入札においてベンダーロックインを避けるため、特定のベンダーや技術に縛られないようにする。最近、このような方針を掲げる自治体や団体も出始めている。 これ自体は良い方針だが、ここで考えなければならないのが、何をもってオープンとするかである。 Web系であれば、利用者の多いLinuxのディストリビューションにApacheとMySQL、それにPHPやJavaのフレームワークを使うということになるのだろうか。ここのApacheはnginxでも良いし、MySQLはPostgreSQLでも良い。フレームワークもあくまでも例なので正直オープンであればなんでも構わない。 だが、この「なんでも構わない」の部分を明確にしておかないと、実際に調達を行う場合、入札仕様書（RFP: Request For Proposal）が書けないので、どっかでオープンの定義を明確にしないといけない。 その定義の難しさ
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート 「2011年1月にHigh Replication Datastoreを立ち上げて以来、App Engineでこれだけ大規模なシステム障害を経験したことはなかった」。グーグルのGoogle App Engine Blogは10月26日付けのエントリ「About today's App Engine outage」でこう書き、同日発生したApp Engineの障害について報告しました。 この障害は10月26日のおおよそ午前7時半から11時30分までの約4時間、 App Engineのリクエストの約半分が失敗するという大規模なものでした。同社は以下のように経緯を説明しています。 ルータへの負荷が全データセンターへ拡大 4:00 am - Load begins increasing o
Google App Engineにデータストアの障害発生。復帰まで約6時間、原因は現在も不明
クラウド上で誰でもJavaやPythonによるアプリケーションが構築できるプラットフォーム「Google App Engine」。 そのGoogle App Engineで、米国太平洋夏時間の7月2日午前6時半（日本時間7月2日深夜11時半）頃から障害が発生し、約6時間のあいだデータストアへの書き込みなどができなくなり、データストア機能を利用する全アプリケーションが影響を受けました。 この障害は午前8時半頃からApp Engineチームによって対応が行われ、午後12時半過ぎには解決した模様です。App Engineチームは逐次作業状況を報告しましたが、何が原因だったのかについては一切明らかにされていません。 Google App Engine System Statusを見ると、たしかに7月2日にDatastoreとMemcacheに障害が発生しているのが分かります。 対策チームからの原因
オバマ大統領も満足したGoogle App Engineのスケーラビリティ
もしあなたが，「オバマ大統領のために，米国民が誰でも質問を投稿できるWebサイトをすぐに立ち上げてほしい」と頼まれたら，どのような見積もりを作成するでしょうか。機能数は少なくていいのですが，ピーク時には全米から毎秒700件ものDBアクセスが集中し，かつ，サーバー障害に対応する冗長性も必要です。 おそらく大手のSIerであれば，ミッドレンジのUNIXサーバーをクラスタリング構成してOracle RACを載せるでしょう。納期は半年，金額は数億円というところでしょうか。腕に自信のある中堅SIerなら，memcached（分散キャッシュ）やMySQLのレプリケーション機能を組み合わせてクラスタリング構成を組み，納期は3カ月，金額は数千万円といった見積もりを出すかもしれませんね。 筆者なら，納期は1カ月，金額は200万～300万円の見積もりを作成します。なぜなら，米Googleのクラウド・サービス「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
