みずほ銀行が大規模障害を繰り返す本当の理由
東日本大震災からわずか3日後の2011年3月14日、みずほ銀行は大規模なシステム障害を起こした。義援金の振り込みが集中したのをきっかけに、振り込みの遅れや店舗でのサービス停止、ATM（現金自動預け払い機）の取引停止などを連発。影響は日を重ねるごとに広がり、収束までに10日間を要した。 みずほ銀行が大規模なシステム障害を発生させたのは、9年前の2002年4月にシステム統合に失敗して以来、2度目のことだ。なぜ失敗は繰り返されるのか。それは、みずほ銀行が根本的な原因を究明し、対策を取っていないからだ。 大規模障害を招いた直接の原因は、システム部門の不手際である。システム全体の仕様や機能をつかんでおらず、バッチ処理の運用時にミスを重ねた。それらがシステム障害の影響拡大につながったのは事実だ。だが、根本的な原因は別にある。 根本的な原因は、みずほ銀行とみずほフィナンシャルグループの歴代経営陣のIT軽
DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール
4月11日から米サンタクララで行われた「MySQL Conference & Expo 2011」。このイベントでDeNAの松信嘉範（まつのぶよしのり）氏が、同社の大規模なMySQLの運用を支えている技術とツールについてのセッション「Automated, Non-Stop MySQL Operations and Failover」を行いました。 プレゼンテーションの中で、社内で利用しているフェイルオーバーの自動化ツールをオープンソース化することにも触れています（英語のドキュメントも作成中とのこと）。 MySQLの大規模運用における自動フェイルオーバーは、特にクラウドでのMySQLの利用が増えるにつれてニーズが高まる分野と思われます。セッションのスライドが公開されていますので、そのポイントを紹介していきます。 自動化されたノンストップなMySQLの運用 ソーシャルゲームでは高可用性が強く求
高速ストレージ「SSD」が主流に、価格性能比でHDDをしのぐ
メモリーの高速性とハードディスクの大容量を併せ持つ「SSD」が普及期を迎えている。容量単価が3分の1程度に下落するとともに、企業向けサーバー/ストレージへの搭載が加速し、主流となってきた。性能ボトルネックの解消を求めるユーザーにとって“当たり前の選択”になりつつある。 「30分かかっていたバッチ処理が30秒に短縮できた」「1年に3台はあった初期故障がなくなった」――。フラッシュメモリーに記録する「SSD」（ソリッド・ステート・ドライブ）が、企業向けストレージ装置の常識をくつがえす。「性能」と「信頼性」が足りないというストレージの課題を一気に解決できる。 「高速だけど高価」というレッテルも過去のものになりつつある。導入コストの低下により、価格性能比で高速ハードディスクを超える製品へと成長してきた（図1）。 ベンダーのSSDシフトが鮮明に 従来SSDは、株式注文など1処理当たりにかかる時間をと
Yahoo! Japanのアクセス障害、原因はロードバランサーの物理障害
10月13日深夜から10月14日にかけて起きたポータルサイト「Yahoo！Japan」のアクセス障害について、ヤフーはCNET Japanの電話取材に応じ、原因を説明した。 Yahoo！Japanでは、10月13日午後11時33分から10月14日午前0時56分の約1時間半の間にアクセスした際、サイトが表示されない、もしくはサイトの一部が表示されても画像が表示されないという障害が発生していた。 ヤフーによると、原因は負荷分散用サーバの一部に物理障害が起きたためだという。「同時期に他社でもアクセス障害があったようだが、調査したところ外部からの攻撃は認められなかった」（ヤフー）。その後、同社では14日1時から約2時間、トップページにてアクセス障害についての謝罪文を掲載していた。今後は広告主などにむけて、個別に状況を説明するとしている。
サーバ管理者日誌 続・クロールとDoSの違いと業務妨害罪と
と書いたのだが、他の図書館でも、一度タイムアウトすると、同じCookieを持ってアクセスすると応答がなくなるという同様の現象が発生するところが見つかった。 気づいたのはたまたまだったのだが、 岡崎市立図書館と同じ、MELILを採用している図書館のリストが、 日本のソフト別OPACリスト[http://www.asahi-net.or.jp/~gb4k-ktr/indexjv.htm#melil] にあり、この中で検索ページが.aspになっているものでは同じ現象が発生する様で、発生条件もかなり緩く、 検索などでのタイムアウト発生 応答が遅かった場合のキャンセル 検索結果ページを閲覧していて、画面内の戻るボタン以外でページ遷移を行った場合 に、以降の応答がなくなるという症状が発生する様だ。 検索ページが.aspxになっているものでは、確認した範囲では発生を見ていないので、これは後に改修されたの
asahi.com（朝日新聞社）：図書館ＨＰ閲覧不能、サイバー攻撃の容疑者逮捕、だが… - 社会
愛知県内の男性（３９）が、自作プログラムで図書館ホームページから新着図書の情報を集めたところ、サイバー攻撃を仕掛けたとして逮捕された。しかし、朝日新聞が依頼した専門家の解析によると、図書館ソフトに不具合があり、大量アクセスによる攻撃を受けたように見えていたことが分かった。同じソフトを使う全国６カ所の図書館でも同様の障害が起きていたことも判明。ソフト開発会社は全国約３０の図書館で改修を始めた。 この問題は同県岡崎市立図書館で起きた。ソフトには、蔵書データを呼び出すたびに電算処理が継続中の状態になり、電話の通話後に受話器を上げたままのような状態になる不具合があった。一定の時間がたつと強制的に切断されるが、同図書館では１０分間にアクセスが約１千件を超えると、ホームページの閲覧ができなくなり、大量アクセスを受けたように見えたという。 男性はソフトウエア技術者で、岡崎市立図書館から年に約１００冊
Twitter、“クジラ”多発の原因を説明
Twitterは6月11日、過去1週間ほどのパフォーマンスの低下について、内部ネットワークの管理にミスがあったためと明らかにした。 Twitterでは6月5日ごろからパフォーマンスの低下やエラーが多発し、過負荷の際に表示されるクジラのイラストが頻繁に表示されていた。同社はその原因として、「2つの重要な高帯域幅のコンポーネントを内部ネットワークの同じセグメントに置いていた」「内部ネットワークの監視が適切でなかった」「内部ネットワークの構成を一時的に誤っていた」という3つのミスを挙げている。 同社はこの問題に対処するため、内部ネットワークのキャパシティを倍増させるとともに、監視を強化し、トラフィックのリバランスを実施しているという。 同社は2009年を通じてトラフィック増大に対処してきたが、「今回の件で分かったように、改善の余地は常にある」とし、ホスティング企業と協力して改善に取り組むと述べて
Linux の nice / renice コマンドを覚えた
毎月１５日は自宅サーバのバックアップが実行される日です。バックアップには２０時間ほどもかかってしまうわけで、実は１５日は凄くレスポンスが低下する日です。ロードは通常時の約３倍の３〜５程度になり、Disk I/O のパフォーマンスが極端に劣化します。 もっともその原因はバックアップの手法が悪いのです。 小さい HDD にバックアップしているために、元々の HDD を tar cvfz 使って圧縮しながらバックアップしているので CPU も凄く喰うんです。こりゃ HDD を増設して差分でバックアップする rsync 方式に変えなきゃ・・・と思いつつ今月もいつもの日が来てしまいました。 さて、今日はいつもにもまして shell での応答が遅いのでプロセスの優先度を変更することにしました。コマンドは覚えてなかったけど優先度設定コマンドがあることは知っていたので調べてみました。 renice - 実
[12_B_6] PHP/MySQL を用いた大規模向けパッケージソフトウェア開発
2. 自己紹介 田中裕一 2007年４月入社 ガルーン開発グループ所属 これまで係わった製品 ガルーン2.5.0 ガルーン2.5.1 ガルーン2.5.2 現在：次世代ガルーン開発
![[12_B_6] PHP/MySQL を用いた大規模向けパッケージソフトウェア開発](https://cdn-ak-scissors.b.st-hatena.com/image/square/c6f84a4606df742a061f9e23d72cf72c48cc903b/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fdevsumi200912b6-1235025833432504-2-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
GIGAZINEが20日（土）から21日（日）にかけて新サーバに移転します
サーバのカスタマイズで乗り切る限界を突破してしまったため、GIGAZINEは今から新サーバに移転します。新サーバ移転後、何か不具合などがある場合には臨時用のこちらのメールフォームからご連絡いただければ助かります。 というわけで以下、旧サーバと新サーバの設定などについて。サーバのカスタマイズに興味のある人向けです。 まず旧サーバは「Dell PowerEdge 850」を利用しており、以下のようなスペックです。よくありがちな構成。 ◆旧GIGAZINE.NETサーバ CPU：Intel PentiumD 930 HDD：73GB(SCSI RAID1) メモリ：2GB ネットワーク：2Mbps OS：Red Hat Enterprise Linux ES3 これが以下のようなスペックの「NEC Express5800 120GR-1c」になります。これもありがちな構成。 ◆新GIGAZINE
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 （この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題」の続きです） キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に（友人たちの）情報を集めることがで
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHP、C++、Memcache、MySQLなどのソフトウェア群によって支えられています（同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照）。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas
ネット史上最大の惨事のひとつ発生―Microsoft Danger、T-MobileのスマートフォンSidekickのユーザーデータのすべてを失う
Unlike Light’s older phones, the Light III sports a larger OLED display and an NFC chip to make way for future payment tools, as well as a camera.
月間1000万ビュー近くのアクセスを自社内の40～50台の中古パソコンでさばくWeblioのシステム：ITpro
Weblioという人気サイトがある。調べたい用語の意味を，200以上の辞書から一度に検索できるサイトだ（参考記事，参考リンク）。2007年2月の実績は，900万ページ・ビュー，120万ユニークIPアドレスを誇る。驚くべきことに，このサイトのすべてのシステムは，ウェブリオ（Weblioを提供している会社）社内に設置された40～50台の中古パソコンでできている（写真1）。 このシステムをほぼ1人で作り上げたのが，ウェブリオ取締役最高技術責任者の佐々木亨氏（写真2右）である。ウェブリオに投資し，同社の社外取締役も務める紀信邦氏（写真2左）は「佐々木氏がいなかったら投資しなかった。彼がいなかったら，同じ事業をするのに10倍のコストがかかる」と語る。佐々木氏は，ハードウエア，ソフトウエア，ネットワークのそれぞれについて豊富な知識を持つ。「特にネットワークに強いのが大きい」と紀氏は評価する。 ウェブリ
オライリー・ジャパン『Make』にはてな自社サーバー開発記掲載＆id:marqsのサーバ開発こぼれ話 - はてな広報ブログ
オライリー・ジャパンから出版されているMake: Technology on Your Time Volume 08という自作/DIY系の季刊誌に、インフラ担当のid:marqsがはてな自社開発サーバーの記事を書きました。 今日は、本誌では書ききれなかったはてなサーバー開発のこぼれ話をご紹介します。 自社サーバー開発までの道のり はじめまして、はてなでエンジニアとして働いているid:marqsです。 2008年5月にはてなに入社して以来、東京オフィスにあるインフラチームに所属しています。インフラチームの中でも、データベースのメンテナンスや、ログ解析、ハードウェアの購買/投入プランニングなどを主に担当しています。 はてなでは、今年5月に新たにサーバーを開発したのですが、実は初期から自作サーバーでサービスを運用していました。旧自作サーバーはid:jkondoが京都の板金工場に依頼して作ったサー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS移行に向けたクックパッドの取り組み
TechCrunch | Startup and Technology News
PC
Expired
3200万人の個人情報漏洩―RockYouのハッカー侵入への対応は最悪