makoto_fujimotoのblog

株式会社進角
代表 藤本信のブログです
どうぞよろしくお願いします

カテゴリ: IT技術

Web上で車のカラーリングやオプションをカスタマイズしてリアルタイム表示しながら見積もりが出来たり、スポーツ用品のオーダーメイドなどができるシミュレーターアプリがあります。開発ソリューションとして古くはShockWaveあたりを起源としてFlashでスタンダード化し、最近はiOSへの互換性を考慮したJavascriptが主流となっています。また各スマホなどに特化したネイティブアプリ形式の開発手法があり、かれこれ10年以上の歴史があります。

導入にはパッケージ(クラウド型もある)を利用したりフルスクラッチで開発する必要がありますが、いずれも高機能であるがゆえ高価なので、費用対効果について十分検討する必要があります。

せっかく導入しても利用されず陳腐化することを避ける為にも導入のメリットとデメリットについてまとめてみましたので参考にしてください。

メリット
1. Web上でオリジナルデザインが出来て完成形がイメージできる
2. アプリを操作すること自体に楽しみがある
3. 費用がすぐに分かる
4. 接客やヒアリングが省略されるので業務が効率化される
5. 24時間365日注文を受け付けることができる
6. 商品への愛着が強くなったりカスタムオーダーサービスのPRになる

デメリット
1. シミュレーション完成までにある程度の専門知識とセンスと根気が要求される
2. アプリが動作する環境に制約がある
3. イニシャルコストと更新コストが高い
4. 技術的な制約があり完全にはリアルの注文と同じことを実現できない
5. 素材入稿や試作が必要な場合がありシームレスなワークフローには出来ない
6. 単価が低かったり数が少ないと収益性が悪い
7. お客さんが思っているイメージと出来上がった商品が違う可能性がある


http://www.goldwin.co.jp/champion/cgi/3dsimulation/teamwear.html

ちなみにこちらの事例はチームウェアのシミュレーターですが、操作してみて感じるのは、エンドユーザーにここまで細かい選択を任せるのは非現実的ではないかと言うことです。リアルに近い注文をWebで実現できるのは良いですが、これでは逆にオーダーに精通した専門スタッフが接客しながら操作するのがやっとのツールになってしまっていないでしょうか。

特に上記のメリット4については販売側の合理性を取り入れると逆に顧客に対して不親切になってしまう可能性があるので要注意です。あと個人的にはこれらのシミュレーターに触れてもあまり目新しさを感じなくなってしまったので販促に繋げるにはよほどのユーザーエクスペリエンスの提供が必要だと思います。

いちおう一般的なビッグデータの解釈はこちらの様になっているようです。
ビッグデータ - Wikipedia
IBM Big data : ビッグデータとは - Japan
ビッグデータ利活用:日立

そもそも既存の大規模事業体やポータルサイトなどの情報サービスは、日常的に膨大なデータを取り扱っているのですが、ビッグデータと非ビッグデータの区別を説明する文脈は整理しておきたいですね。そこで、弊社なりにデータ部分に着目した定義をまとめてみました。

(1) レコード数が1000万件を超えるデータベース
これは単にデータ件数が多いということですが、データ量が300万件を超えるあたりからデータベースサーバを実装・運用する場合の次元が違ってきます。

(2) 電子デバイスによって自動的(無意識)に収集されるデータ集合
GPS情報、環境情報、機械動作情報、生体情報、モーション情報などは、サンプリングタイムが秒や分単位となりますので、情報量が非常に多くなります。またネットワークの発達によって、これらのデータを容易に送信・取得することができますので、集約されたデータは膨大なものとなります。

(3) Webアクションログ
以前のWebサービスのアクセスログは概ね、ページビューや広告バナーのクリックスルーといったアクションや画像等のダウンロードを記録したものでした。最近のWebページやWebアプリはページ遷移を伴わず、オブジェクト単位でHTTP通信を行って画面の状態変更をするものが主流になってきました。しかも現在の技術では、ページ内でユーザがどのボタンをクリックしたか、どのコンテンツをどこまでスクロールしたか、どこにマウスを持って行ったかなど、非常に詳細で冗長なデータを収集する事が出来るようになっています。これらをWebアクションログと区別しました。

(4) 伝統的な大企業や組織が保有する非デジタル情報
メーカーや出版系の会社は図版情報などを紙あるいはマイクロフィルムの状態で大量に保管し続けていると思われます。この様な情報資産に対してデジタイズを行い、メタ情報を付加し、データベース化(インデックス化)を行うことで新たな価値が生まれます。相当な人海戦術は避けられませんが、現業へインテリジェンスのフィードバックを行ったり、新たなビジネスが創出されるかもしれません。

(5) RAW(非圧縮)に回帰したデジタルコンテンツ
これまで映像や音声データはコンピュータの処理能力と通信回線速度の制約があり、圧縮・伸張技術とともに発展してきました。将来的に情報媒体(ストレージ)コストが更に下がり、画像処理性能が向上することが予想されますので、圧縮のための劣化が無い非圧縮データの取り扱いが主流になるのではないかと思います。ちなみに非圧縮のフルハイビジョン映像2時間分のデータ容量を単純計算すると32bit x 1920 x 1080 x 7200sec ≒ 58GBとなりますので、それほど非現実的な感じがしませんよね。 

ぱっと思い浮かんだのは5つだけでしたが、気が付いたら加筆・修正していきたいと思います。

企業がマーケティング施策としてプロモーションサイトで人気投票を行ったり、選挙前に国民世論や政策へのコミットメントを計る為にインターネットを利用した投票システムの利用が増えています。しかしネット投票システムはそのメディア特性ゆえ、図らずも"炎上ネタ"とされたり不正アクセスによって信憑性の低い結果に終わることがあります。

そこで、"炎上ネタ"とならない為にも、現在一般的に実施されているネット投票システムの不正防止機能について考察してみます。

特に何も対策をしない
これは特に重複投票対策を行わず、ユーザが何回でも対象に投票できる仕様ですが、主にコスト面でそうなっている場合と、投票自体がサイトや企画を活性化させる効果を狙ってあえてそうなっている場合があります。設問自体もサイトの盛り上げを目的にした内容なので、投票結果で何かが影響されることが無い場合に向いています。

Cookieを用いた不正防止
ブラウザはWebサイト閲覧の利便性を向上させるために、CookieというデータをPCに記録してログイン状態やショッピングカートの内容の保持などを行う仕組みがあります。このCookieに「投票しましたよ」というフラグを記録しておくことで重複投票が防止できます。
ただしこの仕様には大きな欠陥があって、Cookieファイル自体を消去してしまえば、「投票していない」と同じ状態になるので、この仕組みを熟知しているユーザは不正にCookieを操作することで何度も何度も投票を行う事が可能になります。猛者になると不正投票を行うプログラムを作って、現実ではあり得ないような投票を行うことが可能です。この不正操作によって、最も得票数が低そうな候補に異常な票が集まったりすると、Twitterなどでどんどん拡散して"祭り"や"炎上"といった事態に発展します。

IPアドレスによる不正防止
Webサイトにアクセスする際にユーザは必ずグローバルIPアドレスを持っていますので、このIPアドレスを投票時に記録しておくことで、また同じIPアドレスから投票されても照合して排除することができます。ただしこの場合、企業などで同一ネットワーク中におり、インターネット接続に使用しているIPアドレスは一つだけという環境では、従業員が何十人いても投票できるのは一人だけというデメリットがあります。不正防止には強力な仕様で、投票結果も統計手法的には信憑性が高いものとなると思いますが、投票数が"稼げない"ことがサイト運営者にとって嫌われる事になるかもしれません。

SNS会員認証を利用する
FacebookなどSNSサイトの認証を既に受けている状態を利用して投票を行います。SNSのユーザIDを投票データに保持することで重複の排除に使えると思います。この場合のデメリットはSNSのアカウントが必須なことと、ログインしていない状態では投票できないことです。ちなみに各SNS会社のAPI利用規約などを熟読して利用方法が抵触していないか自己責任で判断してください(ユーザIDを記録するのはNGかもしれません)。

チケット方式
結局のところ、不正防止にはユーザにひと手間かけさせる必要がありそうです。実際の選挙では投票用紙引換券が有権者個人に郵送され、さらに投票所でも選挙違反が行われないように住民登録表と照合が行われたのちに投票用紙が渡されますね。したがってこれと同じ様な仕組みをWebで実装することが最も不正防止になると思います。
例えば投票前に"ネット投票権"を獲得するためにフォームでメールアドレスを入力してもらい、その段階でメアドの重複をチェックして問題が無ければユニークなアクセスKEYをメールで送信します。このアクセスKEYは数千万数億回程度アタックしてもマッチしないような冗長性を持たせます。ユーザは投票の際に候補の選択とともにこのアクセスKEYをチケット(投票券)として入力します。このアクセスKEYは二度と使用できないような仕組みにできるので重複投票はできません。ただし、、このチケット方式でもメールアドレスを任意にいくらでも作れる環境にある人は複数の投票券を得ることが可能なのでもうひと工夫必要ですね。


昨今、若年層の投票率改善やコスト削減の為にネット投票システムの導入が議論され始めていますが、国政を左右するわけですから、絶対に不正や二重投票が起きないシステムにする必要がありますね。そうなった場合でも、郵送によるリアルなインターネット投票用紙の配布は欠かせないのはないでしょうか。

アクセス数やユーザ数の多いサイトを長年運用していると、ある日を境にデータベースのレスポンスが悪くなり、サーバにログインすることも困難になるような障害が発生することがあります。
原因として真っ先に思い浮かぶのは、データ量やアクセス数が多くなってサーバ性能が追いつかなくなったという事です。しかし実際には以前の記事で説明したように、データベースにインデックスが適切に設定されていないことが原因になっていることが多いのです。

1. サーバ状態の確認
まず不具合の検証として、データベースサーバが高負荷になっている時の状況を確認する必要があります。ログインすら出来ない状態であれば、最悪データセンターのオペレータにリセットを依頼する必要があります(立ちあがってくることを祈りましょう)。サーバにログインできたらプロセスやコネクションの状態を確認します。
プロセス数やアクティブなコネクション(ESTABLISHED)がデータベース設定値の上限に達していたら、これ以上リクエストを受け付けることが出来ないパンク状態にあります。

コマンド例
$ ps auxw
$ netstat -na |grep ESTABLISHED

次に原因となっているSQLを調査します。

2. 原因となるSQLの特定
psコマンドの結果で、ある程度負荷の原因となっているSQLが判明する場合もありますが、PostgreSQLやMySQLではスロークエリ、つまりレスポンスに時間がかかったSQL文をログに記録する機能があるので、それをあらかじめ設定して確認する方法もあります。
スロークエリのログを記録していなかったり、閾値が適切でなかった場合はデータベースサーバを確認しても原因となるSQL文が分からない場合があります。その場合は負荷が高かった時間帯のApacheログを確認し、データベースアクセスを伴うスクリプトに当たりをつけます。そしてそのプログラム内で発行されているSQL文を探しあてます。

3. EXPLAINによるSQLの検証
原因と思われるSQL文が確認できたら、実際にデータベースにコマンドモードでログインし、インデックスが有効に効いているか確認してみましょう。SQLのコマンドモードでEXPLAINという命令のあとに続けて、原因と思われるSQL文を入力して実行すると、オプティマイザがどの様なインデックスを使用したか、あるいは使用しなかったか、そしてスキャンされたレコード数やレスポンスタイムなどが確認できます。インデックスが効いていない検索の場合はシーケンシャルスキャンといって、対象となるテーブルを全件頭から最後まで照合しているので大変効率が悪く時間がかかります。

4. インデックスの作成
シーケンシャルスキャンとなってしまっているSQL文が見つかったら性能改善の余地があります。大抵の場合、条件に指定されているカラムにインデックスが設定されていなかったり、マッチング方法があいまいでインデックスが有効に機能していない状態になっています。そして最も簡単で安全な性能改善方法は、検索条件に指定されているカラムに対してCREATE INDEXを行うだけです。この操作はサイトの運用を続けたまま実行できます。
インデックスを作成したら再びEXPLAINでSQLを確認してみましょう。この結果、作成したインデックスが使用されるようになっていれば、レスポンスタイムとも劇的に性能が改善しているはずです。

インデックス作成例
mysql> CREATE INDEX インデックス名 ON テーブル名 (カラム名);

5. 全文検索用インデックスの利用
また良くあるケースでは、全ての投稿記事をキーワード検索(あいまい検索)するような機能を実装している場合にインデックスが効いていない事があります。記事の中から特定のキーワードだけ見つけるような場合に、通常のLike句での検索ではテーブル内のレコードがすべて対象となってしまい、検索効率が非常に悪くなります。このようなケースでは全文検索用のインデックスを使用する必要があります。
以前のフリーSQLサーバなどは、全文検索用のインデックスが標準装備されていないことが多かったので追加モジュールの組込などが必要でしたが、最近のバージョンではおおむね標準実装されている様です。全文検索用インデックスを利用するにはテーブルの属性変更やプログラムの改修、そしてバッチによるインデックス生成などの対応が必要ですが、高い効果が期待できます。

6. まとめ
このように、データベースサーバの性能が悪化してもインデックスの改善でレスポンスが劇的に改善することが非常に多くありますので、ハードウェア増強やクラウド移管を考える前に、まずはインデックスが適切に用いられているか確認することをお勧めします。

某社の大規模データ消失障害における世間の反応を観察していると、いわゆるサーバのデータバックアップについて少し誤解があるようなので整理してみます。

レンタルサーバや各種クラウドサービスやホームページ運用を業者に委託している場合「バックアップって取ってくれてるんじゃないの?」「専門業者なんだから当然でしょ?」と漠然と思われていることが多いのではないでしょうか。

これは情報保全の点では過信しすぎと言わざるを得ません。

ちなみにバックアップと言っても以下の様にいろいろな方式や考えがあります。

RAIDディスク
これはHDDが物理的に故障した際に備えてディスクを冗長化したシステムです。つまりハード故障に備えたもので、人為的ミスやプログラムミスによるデータ毀損はカバーできません。

ローカルバックアップ
これは稼働しているサーバ内のある領域に対象となるフォルダ等を世代バックアップするものです。サーバが同じなのでHDDが飛んでしまったらバックアップも失われることになります。

媒体バックアップ
これは大昔から行われている方式で磁気テープや光磁気ディスクが有名です。記録装置が機械式なので比較的高価となりメディアの交換・保管コストもかかります。最近ではHDDの低価格化とデータ取り扱いの容易さから大容量ストレージを記録媒体とすることが多くなっています。昨今のレンタルサーバやクラウドサービスのバックアップサービスはこの様なストレージを容量制限つきで共有している場合が多いと思います。

FTシステム(あるいはホットスタンバイ)
フォールトトレラントと言いますが、一部のシステムが故障しても自動的に冗長化された機器やソフトウェアの切替が行われ、サービスの継続性を高めた仕組みです。高度な技術が用いられてる為、2重化としてもシステムコストは2倍ではなく5倍以上などと高価になります。非常に難しい仕組みの為、しばし最大手が構築したシステムでも思うように動作しないことがあるようです。

コールドスタンバイ
ハード故障が発生した場合、交換機の調達には何日もかかる場合があるのであらかじめ予備機を用意しておき、いざ故障が発生した場合に速やかにセットアップを行ってサービスを回復させる方式です。その名の通り平時は予備機に電源を入れていない場合もあります。

いずれにしてもバックアップには追加コストがかかりますので、契約上オプション扱いになっている場合が多く、導入時に額面の安さにつられて契約しても適用外になったままの可能性があります。そのうえ全てのISP業者においてデータの毀損やサービスにおける二次損害については保証の対象外となっているはずです(但し重過失をのぞく)。したがってバックアップ方式においてもハード故障または人為ミスのいずれか一方にしか対応できない不充分な仕様になっていないか確認が必要です。

あと冒頭の「取ってくれてるんじゃないの?」という期待ですが、業者によっては自分達の運用上の瑕疵や品質を問われるハード故障、さらにはお客様の人為的ミスで泣きつかれた場合に備えて非公式にバックアップを取っているケースがあるかもしれせん。これはとらえ方によっては個人情報を含む機密情報の無断複製にあたるといえなくもないですが、有事の際には救いになる可能性もありますね。

データベースを勉強する機会があると、必ずデータの正規化について学びます。 正規化とはデータの冗長性を排除したりデータのメンテナンス性を高める設計手法で、かつては高価だった記憶装置の使用コストを削減する目的もありました。またインデックスの効果が得られやすいので、統計やリレーションに使用する項目を正規化(コード化)しておくことでアプリケーションのパフォーマンスを上げることもできます。

 しかしこれを"教科書通り"に行うと開発の生産性を低下させたり、まったく費用対効果が得られないケースが多くあります。

例えばアンケート(性別、都道府県、職業、氏名、媒体、好きなペット、個人情報承諾)を収集するようなデータベースを正規化手法を用いて構築した場合、実データは以下のようになります。
--------------------------------------------------
0,12,3,"フジモト マコト","2|3|7",2,0
1,33,6,"スズキ ユカリ","5|7",1,1
0,35,8,"アマカス ジロウ","1|2|3|5",4,0
--------------------------------------------------
このデータを見ただけではそれぞれの数値の意味が分からないので"人間にとっては"可読性がよくありません。

この例を正規化しない状態(つまり非正規化)にすると以下のようになります。
------------------------------------------------------------------------------
男性,千葉県,自営業,"フジモト マコト","テレビ|ラジオ|インターネット",ネコ,承諾する
女性,岡山県,公務員,"スズキ ユカリ","中刷り広告|インターネット",犬,承諾しない
男性,山口県,パート・アルバイト,"アマカス ジロウ","雑誌|テレビ|ラジオ|中刷り広告",鳥,承諾する
------------------------------------------------------------------------------
と、このようにひと目でそれぞれの項目の意味が分かるので、一次データとしてはこのまま使用できそうです。ちなみに最近のコンピュータは性能が極めて高いので、統計などで数十万件程度のデータから文字列検索を行う場合でも数秒程度しか時間はかかりません。

Webキャンペーン応募などは期間中にアンケートデータを収集するだけの処理(INSERT)が大半なので、検索や更新は運営側の処理が多く、相対的な正規化メリットはとても低くなります。統計やレポートは通常非同期に行われる作業ですから、なんでしたらお手元の素晴らしいバックオフィスソフトで十分処理が可能です。

その昔、途中から関わることになった案件で、性別や都道府県までもがマスタテーブル化、つまり正規化されているシステムを見て驚いたことがありました(当然管理画面もあります)。設計者は何故か性別や都道府県に新たな区分が加わったり変更がありうることを想定していたようです。世の経験値が浅いかコスト意識の低いエンジニアの中には、"正規化すべし"ということを教科書通り真に受けて、費用対効果の低い正規化とテーブル増加を安易に行ってしまう方がいるようです。

以前述べたとおり、データベース(テーブル)数とコスト・工数には強い相関性がありますから、「そんなに細分化したテーブル設計にお金を支払ってくれるなんてずいぶん太っ腹なお客様がいたもんだなぁ」と関心すらしてしまいます。逆にお金と時間を余分に頂かずにこのような設計を行った場合こそプロジェクトが"デスマーチ"となる大きな要因になるでしょう。

正規化とはコストと付加価値を十分見極めて設計する必要があり、つまり"ビジネス要件"でもあるのです。

データベースすなわちテーブルを設計する際、要求仕様にかかわらず、いかなる用途であっても必ず記録した方がよいメタ情報があります。これらの情報記録はWeb系システムの開発を行う組織であれば"データベース設計指針"として社内標準の一つとしてもよいのではないでしょうか。 

  1. 登録日時
    「日時が無い情報は情報ですらない」と言ってもいいくらい必須の情報です。
  2. 更新日時
    データに変化のあった日時を記録することは不具合の検証にも役立ちます。
  3. リモートIPアドレス
    アクセス元を記録することで万一不正アクセスがあった場合の調査やセキュリティ対策に用いることができます。またプロバイダや地域、企業、組織を調べてマーケティングに利用することもできます。
  4. ユーザエージェント
    ユーザが使用しているブラウザ(バージョン)、OS、モバイル・スマホ機器などを分析することで、サイトの品質向上やマーケティングに利用することもできます。

その他に、サーバが複数台となるシステム構成では"サーバ自体のIPアドレス"も記録することをおススメします。どのサーバを経路したかがわかるので、不具合調査(どこのログを見たら良いか)や負荷分散の確認に役立てることができます。またレコードの論理削除を行ったことがわかるように、"削除日時"を設けるケースもあります。

メモリの管理はサーバ運用における重要なファクターとなっており、サーバが高負荷になったりアプリケーションの不具合があると真っ先に「メモリの残量不足では?」という懸念を抱きます。

管理者がメモリ残量を知るためのLinuxコマンドはtopやfreeがあり、以下のようにいくつかの指標があります。

  1. 物理メモリ(total)
  2. 使用メモリ(Used)
  3. 未使用メモリ(Free)
  4. Swapメモリ(Swap)
  5. キャッシュメモリ(Cached)

この中で未使用メモリが不足していたりSwapメモリの使用量が多いとメモリが不足していると判断しがちですが、そうではない場合があります。

OSやアプリケーション(ミドルウェア)はプログラムを展開したりデータ処理を行うためにメモリ領域を必要としますが、処理上一時的に必要なメモリはキャッシュメモリと区別されます。OSの重要な役割として 一度読み込まれたファイルデータは、またすぐに使用される可能性が高いので自動的にメモリ上にキャッシュしておいてくれます。したがってメモリ残が見かけ上は少なくてもキャッシュメモリとして有効に利用されている可能性があるのです。

またSwapメモリですが、その特性上これが発生していること自体を問題視する判断も実は早計となります。OSは各プロセスが、使用頻度が低いつまり必要が無いのに確保したメモリを一定時間経ったらSwap領域に退避してくれる役割もあります。この"すぐには必要とされないメモリ"は上記のキャッシュメモリより優先順位が低い設計になっているようなのでI/O速度が遅いHDDのSwap領域に追いやられます。PCでも久しぶりに操作したソフトが最初やたら重い状態になったりするのは一旦HDDに退避されたメモリが再度実メモリに展開されるロスの為です。

では何をもって"メモリ不足"と判断すればいいのかということになりますが、これはリアルタイムのSwap(ページング)状況を確認するしかありません。

これを観測するにはvmstatというコマンドがあり以下のようにリアルタイムのサーバリソース状況が確認できます。

$ vmstat 2

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0  14220 115632 139708  89896    0    1     2    47    0    0  0  0 100  0  0
0  0  14220 115632 139708  89920    0    0     0    68 1002   35  0  0 100  0  0
0  0  14220 115632 139708  89920    0    0     0     0  996   12  0  0 100  0  0
0  0  14220 115632 139708  89920    0    0     0    14 1001   16  0  0 100  0  0
0  0  14220 115632 139708  89920    0    0     0     0  990   13  0  0 100  0  0
0  0  14220 115632 139708  89920    0    0     0     0  994   13  0  0 100  0  0
この中で注目すべきはsi(スワップイン)とso(スワップアウト)の値です。

こちらの例は実メモリが不足してSwapのI/Oが発生している状態です。このような状態になると速度の遅いHDDへのアクセスが頻発し、サービスへの影響も出ているはずです。

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  8   4028  24016   8900 309828    0    0  4314   926 2710  2445 10 21 31 38
1  1   4036  62672   3268 261384    0    6  4758   872 3037  2861 11 29 26 33
0  1   9920  61368   9248 256728    0 2942  4268  3012 2852  2721  7 31 31 32
0  2  11508  58880  15140 257020  260  794  3322  1596 2202  1955  4  9 46 42
1  0  11836  53304  17472 257184  806  164  2478   638 1936  1450 17  5 44 34
2  0  11836  60528  17692 257684  160    0   402    30 1439   772  4 23 67  6
0  0  11836  58928  17880 258152  192    0   502   532 1322   674  8 35 54  3
0  0  11836  62320  17916 258452  352    0   452     0 1493   799  2  1 94  3

まとめると

  • メモリが不足しているように見えても、キャッシュが非常に有効に働いて良好な運用状態の場合がある。
  • Swapメモリの総量値にはほとんど意味はない。
  • 問題視すべきはリアルタイムのI/O発生で、これが発生している場合は致命的なリソース不足となっていることが断言できる。

情報システムやWebサイトにてデータベース(ここではDBMS)を使用する意義は様々ありますが、主な役割は"必要な情報を整理された形で高速に取り出す機能"になります。

ひとえにデータベースが単なるファイルと異なる点は"インデックス"が使用できるところにあります。

インデックスはその名の通り、ドキュメントの見出しや目次のことですが情報量が増えれば増えるほどその効果が高まります。

例えば以下のような不規則なデータの集合があったとします。
poiuytrgewqlkjhgfdsamnbvcxzaqwertyuioplkjhgfdsmnbvcxzasdfghjklqwertyuiop
この中から"g"という文字の出現回数を数えるには先頭から一文字一文字注意深く観察する必要があります。

この情報が以下のようにアルファベット順に整列していた場合はどうでしょうか、aaabbccdddeeefffgggghhhiiijjjkkklllmmnnooopppqqqrrrssstttuuuvvwwwxxyyyzz
あっと言う間にgが4個あることがわかりますよね。

このようにあらかじめデータの整列を(実際には論理的に)行い、検索時にデータを瞬時に取り出せるような仕組みがインデックスの主な役割です。なお、利用者が数百万人、数億人いるようなSNSサイトであっても瞬時に自分のプロフィールを呼び出して認証を行ったり、変更を行えるのもインデックスが有効に機能しているからです。

しかし、これだけデータベース活用に重要であるにも関わらず、システム開発において中心となるプログラマの中にはデータベースのインデックスについて関心(あるいは興味)やスキルが不足している人が比較的多いという残念な現状があります。開発時や運用初期段階ではデータ件数も少なく、また無理な工期も少なくなくデータベース性能にまで気が回りにくい状況もあるのでしょう。

データベースを運用して数年も経ってから、「最近どうもデータベースのレスポンスが遅い」という現象が発生し、詳細に調査を行ってみたら必要なインデックスが設定されていなかった、なんてことにもたびたび遭遇します。この時きちんとした技術者であれば原因の一つとしてインデックスの不備が思い浮かびますが、安易に「サーバ性能が足りないから」と判断してメモリやCPUの増強を提案される場合も多いです。

私の経験的にはデータベーストラブルの7割以上がインデックスの不備によるものです。

私はインデックスに不備がある状態をお客様に説明する際には「でたらめに本が並べられた本屋で必要な本を探し求めることを想像してみてください」と伝えます。欲しい本が比較的簡単に見つかったり"無いこと"がわかるのは書店の店員がキチンと分類を行い、部分的にあいうえお順に並べてくれるからです。たまに、特に気にしていないと思われる本屋があったりしますが、我慢できるのは商店街にあるような小さな商店までですよね。

Webサイトで動画コンテンツを中心とした比較的規模の大きなプロモーション施策を計画している場合、インフラにおけるユーザの同時接続性能が気になると思います。

ところが一般的なサーバインフラと動画品質を条件として同時接続数を単純計算すると、思っていた以上にユーザ数が少なく見積もられることがあります。


回線速度: 100Mbps
動画ビットレート: 2Mbps
動画の尺: 30秒


こちらの例では計算するまでもなく"同時"接続数はたったの50人となってしまいます。

特に日頃視聴率を気にされるマスコミ関連の方などには「え!少なっ!」という印象を与えるかもしれません。

これをたとえば"1時間あたりの閲覧者数"と謳った場合は以下のようなエビデンスとなります。

転送能力100Mbps x 3600秒 = 360000Mbit

ファイルサイズ(便宜上転送レートと尺から計算)
2Mbps x 30秒 ≒ 60Mbit

360000Mbit / 60Mbit = 6000View

つまり理論上は「1時間あたり6000人の閲覧が可能です」と言ってもさしつかえないわけです。
これならなんとなく納得してくれそうですよね?

ちまみにクラウド界の雄であるAmazon EC2で料金を試算してみますと・・・
1GBあたりの転送料を$0.201=15.5円とします
前で求めた100Mbps回線の転送量をGバイトに変換360000Mbit / 8 = 45000MB = 45GB
したがって料金は最大で15.5円 x 45GB = 697.5円/時間となります

↑このページのトップヘ