こんばんは、ハラです。

2009年もあとわずか！ということで、今年最後のラボブログ更新です！
年末恒例の（？）2009年を振り返ってみようと思います。

まずは、googleがCM広告をしたこの年、
○○とは　で検索されるようになりましたね。
Google Zeitgeistによるキーワードランキングです。

Google Zeitgeistは検索数のランキングではなく、
検索の上昇率を元にデータ化しているので、
ランクインしているものは今年もっとも注目が多かったキーワードランキングになっています。

急上昇ワードランキング

1. ドラゴンクエスト 9
2. 田中 美絵子
3. bing
4. 北野 誠
5. シンケンジャー

「○○とは？」ランキング

1. twitter とは
2. FX とは
3. CSR とは
4. RSS とは
5. アドオン とは

急上昇ワードランキングに「ドラゴンクエスト 9」、「○○とは？」ランキングに「twitter とは」がそれぞれ1位にランクインされていますね。
GoogleでYahooを検索するということもまだあるようです。

2009年、サイブリッジでは社内のみなさまがドラクエ9にハマり、水口代表・シカータ君はついったーを始めました。
先日の説明会でもY先輩、M先輩がおっしゃってましたが、「情報にどん欲になる」「流行に乗る」というのはこういうところから始まるものなのかもしれませんね。

ちなみに2008年だけで900%の成長を達成したTwitterはWebのアカデミー賞といわれる程有名なWebbyでWebby Breakout of the yearを受賞いることでも有名です。


米Yahoo・米Googleから共にランキング1位にあがったのは、世界規模に大きな話題を呼んだ、Michel Jacksonでした。

Windows7など新しいキーワードがありつつ、
Yahooの6位にはNarutoがランクインされています。
ちなみにアメリカのオタク文化にでもっともポピュラーなのは、Narutoなんだそうです。（米友人談）

窓の社 大賞 2009では、Windows7を抜いて「Visual Studio 2008 Professional Edition」が大賞に輝き、個人的に意外な結果になりました。Windows7の発売が10月だったからかもしれませんが。


では、続いてWebデザインのトレンド2009年。
SMASHING MAGAZINEからエントリーされた Web Design Trend for 2009と、追加エントリーから。

エレメント

透過PNG。
IE6用の優良Javascriptが増えて、積極的に透過PNGを取り入れているサイトがどんどん増えてきたのも今年です。

テキスト置換：
HTMLテキストをJavascriptでFlashムービーに置き換え、
アンチエイリアスが掛かった選択可能なテキストとして表示させたり、
テキストの上にグラデーションの透過PNGをかけて表示、などといった手法も出てきてました。

リッチユーザインターフェース、コンテンツ

モーダルダイアログボックスなどJavascriptでのポップアップボックス（Lightroom等）、
Flashを使用した動画配信や、Flash/Javascriptのスライドショー形式が増え始め、
あらゆるサイトで取り入れていました。

レイアウト

ページ遷移無し・1ページのみのレイアウトや、色鮮やかなグラフィックを全面に出して印象付けるレイアウト、
また、ミニマムに余白スペース領域をとったレイアウトといったレイアウトに人気がありました。

テイスト

水彩画デザインを始め、手書き、ノート・メモ帳など、
テイストとしてはレトロ・ビンテージ、グランジ系といった
どちらかというとモニター外で見かけるモノを取り入れたデザインなどが注目されていました。

SMASHING MAGAZINEからはまだですが、Web Design Ledgerでは、2010年のトレンドが発表 されています。
レイアウト・エレメントデザインの他にも、CSS、Scriptなどにも勿論、トレンドってあるんです。

たとえば色。
ちょっとWebから離れますが

PANTONEが選んだ2010年のトレンドカラー

参考：Splashes of sunshine for spring 2010（英文）
一般的に流行色と言われるものは、
INTERCOLOR、JAFCAが発表していますが
PANTONEからも毎季節のトレンドカラーが発表されています。
PDFもDLできるので、是非みなさんチェックしてみてください。


それでは、みなさん
メリークリスマス＆よいお年を！！

今年も残すところ僅かとなりました。
ボブです。

システムの絡んだWebサイトの性能問題に対面した時、最終的にはスケールアップやスケールアウトといった形でサーバを増強していく事になります。今回はLAMP環境を想定してその概要をまとめたいと思います。

なお、挙げている例はあくまで性能問題に対する構成例ですので可用性を得るためのHA構成などは省略しています。

99%のケース

Web+DBサーバ1台構成

最も多い構成で世の中の90%のサイトはこれで事足ります。90%という数字は数値的な根拠は無く体感です。1台のサーバにWebサーバもDBサーバも積んだ最もシンプルな状態です。

Webサーバ1台+DBサーバ1台構成

1台のマシンでやってきてアプリケーション側の主なボトルネックも解消され、後はもうサーバリソースを増やすしか無いという段階で一番容易に対応出来る構成です。両サーバをスケールアップ、設定のチューニングをしていく事で残りの9%のサイトに対応する事が出来ます。ただし2台のマシンのどちらも単一障害点のため、どちらかが故障するとサイトがダウンするといったデメリットはあります。

Webサーバ2台+DBサーバ1台構成

画像など静的コンテンツの配信負荷が高い場合、画像のみ別のWebサーバに配置するという負荷対策もあります。(負荷対策以外の理由で分離される場合もありますが割愛)
こういったケースでは予算次第ですがCDNの利用等も選択肢になります。

残る1%

ここまでは単純にサーバを増やすだけで対応していける範囲ですが、それでも性能問題に直面する場合にはスケールアウトを意識したアプリケーション設計にする必要があります。

Webサーバのスケールアウト

ロードバランサー等が必要になります。比較的高価なハードウェアロードバランサー、OSSを利用した安価なソフトウェアロードバランサー、等色々な選択肢があります。DNSラウンドロビンでロードバランスする方法もありますが、携帯端末(一部？)やVista以降のIEでは利用出来ないそうなので、注意が必要です。

PHPで構築している場合Webサーバが複数台になるとセッションをどこに保存するのか、という問題にも直面します。選択肢としてはDBをセッション保存に利用する、KVS(Key Value Store)を利用する等、状況によって最適解は異なってきます。

参照系DBサーバのスケールアウト

MySQLの場合Read負荷が問題であればレプリケーションで参照専用サーバを増やしていく事で対応する事が出来ます。或いはmemcachedのようなRDBよりもパフォーマンスの高いKVSをDBキャッシュサーバとして利用する事も出来ます。

ただしアプリケーション(Webサーバ)からどのDBサーバへ接続しにいくのか、という問題を解決する必要があります。参照系DBと更新系DBのどちらに接続するか、という制御はアプリケーションフレームワークで行うのが一般的でしょう。(KVSをDBキャッシュとして利用する場合の制御も)

参照系DBの中でどのサーバを見に行くか、という問題はアプリケーションと参照系DBサーバの間にロードバランサーを挟む事で解決する手法もあります。

MySQL の負荷分散に LVS + keepalived を使う

この構成であればアプリケーションから見た参照系DBサーバが1台に見えるので、アプリケーション側で楽をする事が出来ます。

次にWrite負荷が問題になるケースですが、RDBMSで対応する場合にはDBを分割(sharding)していく必要があります。ただしこれをやってしまうと通常、DB設計の変更や管理などが非常に大変になってしまうため、頻繁な機能追加や変更が想定される場合には特に注意が必要です。いっその事MySQLよりも更新性能の高い別のDBMSを用いるといった選択もあるので検討が必要でしょう。ただKVSをストレージとして利用する場合、RDBであればDBMSが面倒を見ていてくれていた整合性維持の問題等をアプリケーション側で解決する必要があります。

DBの垂直分割(Level1分散)

例えばブログ機能とニュース機能を持ったサイトで、ブログ機能専用DB、ニュース機能専用DBに分割するようなイメージです。或いはユーザテーブルを基本情報テーブルと拡張情報テーブルに分割する等。

DBの水平分割(Level2分散)

例えばユーザテーブルであれば、ユーザID10000番台だけほ保存するテーブル、ユーザID20000番台だけを保存するテーブル、といった形で分割していく手法です。上記のレンジ分割、ハッシュ分割などの手法があります。

これまでのスケールアウトとこれからのスケールアウト

色々と端折っていますが、以上がLAMP環境でのスケールアウトの概要になります。最後に少しだけ今話題になっている「クラウド」についても、触れておきます。

Amazon型クラウド(EC2)

Amazon型クラウドではサーバの追加が非常に容易です。このためスケールアウトを前提にした設計になっている場合、急な負荷増加に素早く対応する事が出来ます。またリソース課金に近いのも特徴です。既存のLAMP環境でのノウハウもそのまま活用する事が出来ます。

Google型クラウド(GoogleAppEngine)

ここまで説明して来た技術とは異色で、そもそもスケールアウトしやすい技術しか用いずWebサイトを構築する、というアプローチです。このためスケールアウトしにくいRDBMSは使えずGoogleが用意しているオブジェクトストアと呼ばれる物に、GQLという問い合わせ言語でアクセスする事になります。リソース課金のためCPUや帯域を使えば、使っただけ請求が来るという特徴があります。

言語の制約(現在はPythonかJAVA、又はJAVA上で動作する言語)等もあり、既存のLAMP環境でのノウハウが全てそのまま活かせるわけでは無いというハードルの高さがありますが、適用ケースによってはコストメリットがあるのではないでしょうか。

このあいだ iPhone アプリに今までいくら使ったのか調べたら、3万くらい使ってたことに気付いてちょっと反省しているハシモトです。（App Store Expense Monitor で調べられます）
今日は画像置換について書いてみたいと思います。

画像置換とは

画像置換とはCSSのテクニックのうちの一つで、HTMLでマークアップしたテキストをCSSでテキストを隠し、画像に置き換えて表示させる手法のことを言います。
この手法はalt属性が必要でない画像を使用するとき、つまり完全にデザイン目的だけで画像を使用するときに使われたりします。

メリット

1. 文書構造とデザインをHTML・CSSで分離でき、CSSだけで見た目のコントロールができる
2. altのテキストを検索対象に含めない検索エンジンに対してSEO的に効果があるかもしれない
3. background-positionプロパティを応用して、ロールオーバー画像をJavaScriptなしでも再現できる（CSS Sprite）

などが挙げられます。
3番目は弊社の運営する「塾講師ナビ」やその他の媒体でも活用していたりします。

デメリット

1. テキストの内容と画像の情報が等価でない場合、SEOスパムと判定される可能性がある
2. ブラウザの初期設定だと背景画像は印刷されない、CSSがオンで画像がオフの閲覧環境だと何も表示されない
3. 画像置換の方法によっては、音声ブラウザで読み上げられなくなる

などが挙げられます。
メリットだけでなくこういったデメリットもあるのを認知した上で使用します。

画像置換の手法

1. FIR（ファーナー式）。空のspan要素に display: none; を指定してテキストを消す方法。
2. Phark方式。text-indent: -5000px; などマイナスの値を指定して画面の外にテキストを飛ばす方法。

などがよく見られる手法ですが、今回ご紹介するのは

LIR（リーフィー/ラングリッジ式）

と呼ばれる height: 0; と overflow: hidden; をうまく使った手法です。

サンプル

HTML

‹h1 id="sample"›‹a href="hogehoge"›サイブリッジラボ‹/a›‹/h1›

CSS

#sample {
	width: 120px;
	height: 30px; /* 置き換える画像の高さ */
	overflow: hidden;
	background-image: url("/img/common/hogehoge.gif") no-repeat;
}
#sample a {
	display: block;
	width: 120px; /* 置き換える画像の幅 */
	height: 0;
	padding-top: 30px; /* 置き換える画像の高さ */
}

まず height で高さを 0 にしてテキストを隠した後、
padding-top で画像の高さ分を空けて、背景の画像を表示させるというアプローチになってます。
Mac や iPhone でおなじみの Apple のサイトだとこの手法を使って画像置換をしていますね。

画像置換の今後について

HTML5 が普及してくると、img要素のalt属性に関しての仕様がちょっと複雑なことになったり、（参考：HTML5のimg要素のalt属性の仕様は読んでおくべきだと思う。｜CSS HappyLife）
CSS3 が普及して、ウェブフォント（@font-face）が多くのブラウザで使えるようになってきても、
日本語に関してはライセンスの問題であったりファイルの容量などで、しばらくはこれからも画像置換のテクニックが用いられていくんじゃないかなぁと思っています。
英語圏に関しては Typekit など盛り上がっていって面白いことになりそうですね。

そんなこんなで画像置換のお話についてでした。

とくながです。
ECサイトは実際の商品やマーケティング手法が重要ですが、
サイト自体のインターフェイスによっても売り上げが変動します。

最近ではシステムに実装されているデザインテンプレートも
充実していますが、今回はもっと美しいECサイトをデザインする際に、
参考にできそうな4エントリーをピックアップしてみました。

 

50 Inspirational E-Commerce Website Designs

ECサイトのまとめエントリー。
海外サイトですが日本でも割と有名で、
作り込まれているECサイトのデザインが
50種類もまとめられています。
リンクを辿るだけでも新しい発見が。

ecommr

こちらも同じくデザインのまとめサイト。
サイト単位ではなく、インターフェイスや
バナー画像などを中心にまとめられおり、
買い物かご、サーバーエラー、ナビゲーションなど
部分別のデザインを参照可能となっています。

107 Add to Cart Buttons of the Top Online Retailers

「買い物カゴに入れる」ボタンを集めたエントリー。
107種類ものボタンを見ることができます。
ECサイトを構築する上で重要なパーツなので、
デザイナーにとっては参考になる記事ですね。

30 High-Quality Icon Sets for E-Commerce Designs

カートやクレジットカード、配送のイメージなど、
ECサイトでの利用に特化したアイコンのまとめ。
Web2.0っぽいデザインが多いようです。
こうした素材って結構お世話になること多いですよね。

 

日本では楽天やYahoo!ショッピングのような「チラシ」っぽい
デザインが主流ですが、扱っている商品や店としてのコンセプト、
ターゲット層などを分析しベストなデザインを模索しましょう。