読者です 読者をやめる 読者になる 読者になる

わかりやすい

主にIT関連や時事ネタの興味を持ったことを、なるべくわかりやすく書いてみようとおもいます。

スポンサーリンク

2016年4月版 CMSトレンド(簡易版)

とあるWebサイトを作ることになりそうで、CMSについていろいろ調査中。 調べれはすぐわかることばかりだけど、簡単に整理しておきます。

目次

CMSとは?

「Contents Management System」の略で、要するにWebサイト(ホームページ)を簡単に更新する仕組みのこと。

2016年4月版 CMSトレンド(簡易版)

多く使われているのは以下の3つの模様。

それぞれ特徴があるが、記事にできるほどちゃんと理解していないので、詳細は別記事にて。

現時点での自分の理解は以下の通り。 ※ちゃんと使い込んでいるわけではないので、推測をかなり含みます。

WordPress

  • シェアNo.1
  • 情報が多い
  • ブログ向き

Joomla!

  • シェアNo.2
  • 大企業サイトでの採用率が上がっている(WordPressとの差が縮まっている)
  • カスタマイズの幅がDrupalに比べて狭い
  • 管理画面が使いやすい
  • シンプルなWebサイトに向いている

Drupal

  • シェアNo.3
  • 大企業サイトでの採用率が上がっている(WordPressとの差が縮まっている)
  • 動作が軽快
  • カスタマイズの幅がJoomla!に比べて広い(簡単かどうかは別の話)
  • 管理画面がそこそこ使いやすい
  • 多機能なので大規模なWebサイトに向いている

蛇足

自分が今回作るサイトはJoomla!が向いてそうだけど、 自分とお客様との関係性を考えると、ノウハウとして持っておいたほうがいいのはDrupalのような気がするので、自分はDrupalを掘り下げてみようと思う。

2016年3月22日に発生したANAのシステム障害について、ANAが日本ユニシスへの損害賠償を検討している

表記の件を考察してみる。

例によって、ANAさんとか特定のSIerさん、ベンダーさん、メーカーさんとかを批判する意図はありません。 不幸にも社会的インパクトがあったシステム障害について、 エンジニアとしてどう向き合うべきかの糧にしたい、という思いで書いています。 (というわけで、今更ですが表記が気持ち悪くならない範囲で個別の社名は書かないことにします。)

参照した記事は以下。

itpro.nikkeibp.co.jp

目次

損害賠償の根拠・理由

損害賠償というからには「U社さんがとある債務を履行しなかったことが今回のシステム障害の原因であり、ANAが損害を被った原因である」という論法になるはず。

もはやここから先はANAとU社さんの個別の契約の話なので、私のような第三者がとやかく言う内容ではないわけですが、

  • ANAは上場企業であり、世界中に数多くの株主が存在する
  • 会社は法律を遵守した上で、株主の利益を最優先に考える
  • ANAは株主の利益を守るために、行うべきことは行わなければいけない
    • でないと、役員が株主から「債務不履行」で損害賠償請求をされてしまう

こんな事情があると思われるので、ANAも株主に「ちゃんと株主利益考えてますよアピール」としての「損害賠償請求の検討」をいわなければいけなかったと推測。

U社が履行すべきだった債務とは?

個別の契約の話なので超推測ですが、帰着するのは「なんで冗長化してたのにシステム全体が止まっちゃったの?」という点だと思われる。

2016年3月22日に発生した、全日本空輸株式会社(ANA)の国内線システム障害についての考察 - わかりやすい

にも書いた内容に少し関連するけど、

  • 設計が悪かった←設計者の瑕疵
    • 「故障時、どういうメカニズムでシステム全体として動作が継続できるのか」のアイデアに不備があった
    • 例えば以下のようなアイデア
      • 故障機が故障シグナルを送信することでフェイルオーバーさせ、システム全体として動作を継続させる
      • DBサーバは同期が必要であり、同期ができなくなったら不整合の発生を予防するため、停止させる
  • 設計は適切だったけど、設計を実現する機器の選定を誤った←機器選定者の瑕疵
    • 機器が、設計どおりに動くための要件を満たしていなかった(今回の機器を選定したのが悪かった)
  • 設計は一見適切だが、設計を実現する機器が世の中に存在しない←設計者の瑕疵でもあり、「そんな要件満たす機器はありません」と指摘できなかった機器選定者の瑕疵でもあると思われる
    • 「故障機が故障シグナルを送信することでフェイルオーバーさせる」は、故障機に何かしら動作を期待している時点であやしい

ほかにも「運用が悪い(障害が長期化したのは、構築時に想定していた復旧手順を適切に履行しなかったことが原因である)」、という主張も出てくるかもしれませんね。

教訓

仮定(推測)の上に教訓もへったくれもないですが、

  • 無理が通れば道理が引っ込む
    • 「絶対止めるな」に対しては「コスト」か「納期」か「嘘(実は止まっちゃう)」で責任を取ることになる
    • システム要件は現実的なものを定義しましょう
    • 設計はシステム要件を最低限満たす、シンプルなものにしましょう
    • 機器選定は、設計要件を最低限満たす、稼動実績の高いものにしましょう
  • 実は運用が一番大事ですよね
    • 運用してシステムとしての役割を果たさせる(目的)ために構築する(手段)のであって、「作った(目的)ものを動かし続けなければいけない(尻拭い)」ではないはず
  • 無理・誤りに気づき、適切なレールに戻せると幸せですね
    • だいたいシステム作るときには、予算と納期(下手すると採用すべき機器まで)が決まっているのに、要件はぜんぜん決まっていない、なんてことがよくあるので、まぁ、難しいですよね…。

ITによって世の中がもっと便利になりますように。 また、それを支える側にも適切な責任と利益が与えられますように…。

2016/04/04頃にWindowsの時刻が1時間くらい進んだ?

(2016/04/05 10:00 対処方法の記事を書きました。) 2016/04/04頃にWindowsの時刻が1時間くらい進んだ件の対処方法 - わかりやすい

自分のWindows 7が表記の事象に遭遇。

Windows標準のNTPクライアントはtime.windows.comを向いてた。 最終同期時刻は2016/04/04 01:00だったはず。再同期したら直ってしまった。

調べてみると、似たような症状に合ってる方がちらほら。

少なくとも自分の環境が原因ではなさそう。

適当なデスクトップだから時刻が対象ずれるのはかまわないけど、Windows Serverとか大丈夫なんだろうか? 自分が面倒を見てるWindows Serverは幸いにもtime.windows.comを向いたものはなかったから確認できず。

2016年3月22日に発生した、全日本空輸株式会社(ANA)の国内線システム障害についての考察

表記の件について、エンジニア目線で考察してみる。

なお、原文は以下。 www.ana.co.jp

ちなみにANAさんの発表は株主や顧客に対してできる限りの説明責任を果たすためのものであって、 世のエンジニアに何が起きたのかを教えるためのものではないので、 今のANAさんの発表内容を批判する意図の記事ではないです。

目次

システムの構成

ANAさんが公表している構成図 www.ana.co.jp を参照。ポイントは以下。

  • DBサーバが4台あり、同期が必要
  • DBサーバにはAPサーバとの通信用通信路以外に「同期通信用の通信路」がある
  • 同期通信用の通信路を「ネットワーク中継機」が実現している
  • ネットワーク中継機には予備機が存在し、ネットワーク中継機が故障した際は予備機がその機能を引き継ぎ、DBサーバ間の同期通信が正常に行える状態になる

何が起きたのか

  • ネットワーク中継機(他の報道によると、シスコシステムズ合同会社Catalyst 4948E)が故障したにも関わらず、予備機が正常にその機能を引き継がず、DBサーバ間の同期が正常に行えなくなった
  • 結果的にアプリケーションが正常に動作しなくなった

考察したいポイント

  • 今回の事象(ネットワーク中継機の故障)が発生した際、具体的にどのように予備機に切り替わる想定だったのか
  • 今回なぜそのように動かなかったのか

どのように予備機に切り替わる想定だったのか

ANAさんの発表から部分引用

本来であれば、ネットワーク中継機が故障すると「故障シグナル」を発信し、予備機に自動的に切り替わる設計になっておりますが、

  • (故障したネットワーク中継機が?それ以外が?主体不明)「故障シグナル」を発信する
  • (ネットワーク中継機の予備機が?それ以外が?主体不明)「故障シグナル」を受信し、予備機に自動的に切り替わる

ここがキモですが、主体不明なので切り替えのメカニズムがいまひとつ見えてきません。

今回なぜ、想定どおりに動かなかったのか

今回は故障しているにも関わらず「故障シグナル」を発信せず、予備機に自動的に切り替わりませんでした。

ここは前段のメカニズムが明らかになれば、ある程度納得できそう。

もっと知りたい点

故障シグナルを発信する主体は誰(どの機器)で、何をもって故障と判断するのか

  • 誤検知(false positive)や見逃し(false negative)は起こりうるのか?
  • 仮に故障シグナルの発信主体が故障機自体だとすると、見逃しは簡単に起こりそう。(例えば電源断とか)

故障シグナルを受信するのは誰(どの機器)で、受信後どのように振舞うことで、全体として動作継続するのか

  • (発信主体による見逃しも含め)故障シグナルの受信に失敗したらどうなるのか
  • 発信主体の誤検知による故障シグナルを受信したらどうなるのか

「2.再発防止策」の「(1)同一事象の検知」について

同一事象が再発し、ネットワーク中継機が「故障シグナル」を出さない場合でも、データベースサーバーからネットワーク中継機の故障を検知できる改善を実施しました。(2016年3月24日に実施しました)

  • 故障シグナルの受信者はデータベースサーバーなのか?
  • 故障を検知(他の3台のデータベースサーバーと同期が正常に行えないことを把握)したデータベースサーバーはどう振舞うのか?その際、システム全体として処理が継続できるのか?

「2.再発防止策」の「(2)メーカーによる改善策」について

不具合のあった機器は、製造メーカーにおいて解析を実施し、故障個所が判明しております。 現在、製造メーカーにて改善策を検討中です。

  • 故障箇所は具体的にどのレベルまで判明しているのか?
    • ハードウェア?
    • ソフトウェア?
      • OS?
      • その他何らかの機能?(例えばVRRPとか)
        • 問題のあった振る舞い?(例えば「Masterが居なくなった際に自身(Backup)がMasterに昇格する振る舞い」とか)

不具合の発生条件

※このセクションは3/31 15:20頃追記しました

中継機の故障内容は以下の2点とされています。

  • 中継機能の故障
    • トラフィックの転送そのものができなくなった、ということと推測
  • 「故障シグナル」の発信機能の故障
    • 聞いたことのない機能なので、詳細不明

これらの故障の原因(トリガー)が気になる。

itpro.nikkeibp.co.jp

上記には

「本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ、不具合が再現した」(ANA広報)

とあるので、トリガーは判明していると思われる。

まとめ

正直エンジニアとしてはこの内容ではさっぱりわからない。 続報があれば記事の修正なり別記事を書くなりしたいと思います。

この記事の改定履歴

  • 2016/03/31 15:20頃
    • もっと知りたい点に「不具合の発生条件」を追記
    • ANAさんの報告ページのURLが変わっていたので差し替え

Ubuntu 14.04 LTSで仮想化環境構築

wakariyasui.hatenablog.jp

上記で書いた、vyosを動かすための仮想環境の構築方法について。

前提

  • 仮想化支援対応のCPUでUbuntu 14.04 LTSが動作していること
  • Ubuntu desktop(いわゆるUnity)が動作していること
    • Ubuntu GNOME desktopでいいと思うけど、自分の環境はUbuntu desktopだったということで
  • 物理NICが2枚あること

手順

必要なパッケージをインストールする

sudo aptitude install qemu-kvm qumu-system libvirt-bin bridge-utils virt-manager

一度再起動する

virt-managerの起動に、ユーザがlibvirtdグループに所属する必要があるけど、それがインストール直後だと反映されていないので、反映するために再起動 再起動じゃなくても反映する方法はありそうだけど、面倒なので再起動にした

virt-managerを起動する

普通に動くはず。 あとはお好みでネットワークとかストレージとか仮想マシンとか作ってください。

DELL Inspiron 1501にUbuntu 14.04 LTSをインストール

手元にあったのでUbuntu入れてみることにした。 目的はUbuntu上で仮想マシンとしてvyosを動かしてVPNを張るため。その件は別記事にでも書こうと思います。

前提・要件

  • Ubuntu 14.04 LTSをネットワークインストールする
    • ネットワークインストール用のISOを焼いたCDなりDVDを用意しておく
    • 有線(DHCP)でインターネットに接続できる環境がある前提
  • デスクトップ環境はUbuntu desktop(いわゆるUnity)をインストールする(重いだろうけど…。)

結果

  • Ubuntu desktop(Unity)は重いけど、ちゃんとインストールできた
  • 無線LANは初期状態だと使えなかった(認識しなかった)けど、ファームウェア的なものをインストールしたら使えるようになった

手順

ネットワークインストール用のCDなりDVDなりを用意する

  • ここにネットワークインストール用のisoがあるので、ダウンロードして焼いておく
    • 使うイメージは「amd64 - For 64-bit Intel/AMD (x86_64)」のリンク先にあるmini.iso
    • なぜならInspiron 1501は64bit CPUを積んでいるから

CDなりDVDを入れて起動、インストールを開始する

  • BIOS(電源を入れたあとにF2を押す)でDVDドライブの起動順をHDDよりも上に持ってこないと、今HDDにインストールされているOSが起動しちゃうので注意
  • 起動したら普通にインストールを進める
  • 途中のパッケージ選択では「Ubuntu desktop」だけを選択して進む
  • インストールが完了したらDVDを取り出して再起動

無線LANドライバをインストールする

  • 起動すると無線LANが使えない(しかも起動時にfirmwareなんちゃらのエラーメッセージ的なものが表示される)はず
  • 端末を開いて以下で必要なドライバをインストール (こちらを参照)
  • 再起動して動作することを確認する

ちゃんと動きましたね、よかったよかった。

Intel Rapid Start Technologyがインストールできない

表記の件。インストールしようとすると、以下のようなエラーが出る。

「このシステムは、このソフトウェアをインストールするための最低要件を満たしていません。」

この問題に対する対処方法を整理する。

前提

Windows 7 Home Premium

状況の確認

  • 「スタートボタン」をクリック、「コンピュータ」を右クリック、「管理」をクリック
  • 「コンピューターの管理(ローカル)」配下、「記憶域」配下の「ディスクの管理」をクリック
  • コンピュータに搭載されているメモリ量と同じサイズの「休止パーティション」が存在しないことを確認する

ここまで確認できたら解決までは恐らくシンプルに進む。

原因

Intel Rapid Start Technologyを動作させるために必要なパーティション(コンピュータのメモリ量と同じサイズの休止パーティション)が存在しない

※推測ですから参考まで。

解決方法

  1. コンピュータのメモリ量を確認する
    • 例えば8GBだったとする
  2. 休止パーティションを作成するための未割当領域を作り出す
  3. 休止パーティションを作成する
  4. Windowsを再起動する
    • 私はこれをせずにハマりました
  5. Intel Rapid Start Technologyのセットアップを行う
    • うまくいけば、冒頭に紹介したエラーがもう出ないはず

参考になれば幸いです。