案件・業務の進捗記録と備忘録

日本語のGoogleマップでリリースされたストリートビューですが、さっそく見てみました。

当方としては、気になるのはやっぱり技術面です。どうやってやってるんだろうと思いまして、ぱっと考えてみました。まず、６台のカメラを用意して、正立方体の外側の法線ベクトルにカメラをセットします。サイコロの各面の真ん中に、広角のカメラがある・とかんがえればいいでしょう。それで、車を走らせながら、一定の距離間隔で（ないしは交差点などの特殊なポイントにおいて）シャッターを切ります。その各面に撮影されたデータにパースペクティブをつけて、Flashで各面をつなげれば出来上がり…ではないでしょうか。全部、推測ですけれども、これが最もコストが低いと思います。

当方は、昔からゲームなどの「街の表現」が大好きで、車のゲームの背景・町並みとか、２次元のときは多重スクロールでの表現、古くはVRMLでのウォークスルー、ポリゴンの表現コストが下がってからは、街に関しては表現力が上がったことを素直に面白がっています。その感覚に近いものがありますので、「ぱっと見、面白い試み」と、まずは感じます。

当方は、著名な建築物などを見て、「おお、すげえ！」などと楽しんでいたのですが、多くの人のストリートビューの楽しみ方は、「いかに面白いショットを見つけられるか」にあるようです。例えば、自分の家の部屋の窓・たまたま撮影されたときに面白いポーズをしている人・撮影しているときの車を見つめている少年・風俗街や歓楽街周辺や施設の出入り口など、みなさん色々と面白そうな写真を発見・報告をして「遊んでいる」ようです。

こういった興味の方向からもわかるように、このストリートビューは、プライバシーという問題と切り離して考えることは出来ません。これまでにも、ライブカメラや風景写真などがネットで公開されていましたが、それらの情報は土地所有者の主体管理下に置かれていること、被写体(場所・シーン)は、プライバシーの公開に同意できる・例えば、情報発信者自身の部屋であること、ないしは公共性が著しく高い(＝駅や公園など、人の出入りが激しく居住空間などではない)場所であることが、暗黙の大前提であるように思います。

ネットを離れたケースで考えてみましょう。道路に立っている人が、あなたの家の中を凝視していたとします(見えるかどうかは別として)。この場合、「いや、この道路は公共の場所だ。俺は、そこに立っていて、たまたまそっちを向いていただけだ」と言っても、それが問題に発展することは容易に想像できます。とある個人が、一市民である、あなたの家の写真を道路から撮って、「誰某の家」とインターネットで公開することは、問題があると考えられます。肖像権に関しても、「公人」「私人」は、区別がなされています。

これまでのGoogleマップよりもプライバシーが問題になりそうなのは、このストリートビューがあまりにも細かく鮮明な、道路以外(道路は公道でパブリックなものですが、そこを一つ超えた個人の敷地内などは、パブリックな場所ではありません)の周辺状況を持っていること、更に加えて言うなら、情報を元にした検索エンジンや広告宣伝事業を行っている、情報を牛耳って自在に操る企業「Google」によってデータが管理されていることでしょう。

ストリートビューのサービスは、プライバシーの問題において、海外では裁判に発展する事態にもなっています。Googleの主張としては、「衛星画像技術においても完全なプライバシーは存在しない」(参考：Google幹部の自宅をプライバシー保護団体がさらしものに)という見解？や、同記事によれば、Google社ビント・サーフ氏の「プライバシーなどは存在しない」といった主旨の発言があり、自社の技術とサービスに問題はなく、受け入れられる自信があることを訴えています。

そもそも、Googleのサービスには、研究開発の結果がそのままサービスに供されているような内容のものが多くあり、それが何かの先進性を感じさせたりするのですが、今回のストリートビューに関してはどうでしょうか。GoogleMapの開発チームが面白がるあまり、なにかの一線を踏み越えてしまっているのかもしれません。ぼかしを入れたからいいだろうとか、今や誰でも写真を撮ってネットで公開できる時代なんだという主張は、インターネットだけを背景にした強弁ではないでしょうか？

技術面で言えば、GoogleMap開発チームの感じているであろう面白さは理解できます。但し、それほど技術開発のコストが掛かっているわけでもなく、単に写真をつなげただけに過ぎません。仮に、写真をアニメ調にデフォルメして加工表示する技術を開発しているとか、画像から建物の頂点を取り出してポリゴンに変換して表示データの基礎にするような技術だったら、それはすごいですが、ストリートビューは「写真撮影の取材におけるコスト」だけが突出している状態でしょう。これが、例えばX3Dなどで表現されていたら、うわーGoogleすげぇ！と、拍手を送りたくなるのですが、このストリートビューは、写真をそのまま使うという、技術としてあまりにも単純で簡単すぎるお陰で、リスクや問題を内包しているように思えるのです。今後に注目ですね。

追記：画面データをどのように送っているかに興味があったので、調べてみました。360°カメラを使用しているのでは？という見解があったのですが、画面をみていると、360°カメラを使用しているにしては、不自然な画像のつながりが多い。それで、画像データを引っ張り出してみると、普通のパースを持ったカメラで撮影した画像を基本データに持っていることは間違いなさそうで、それにパースペクティブを与えて画面をつないでいるらしい感じがしました(この処理をリアルタイムでやっているかどうかは不明ですが、予めデータを作ってあるような気がします)。これは、歩道部分など地表の部分と、それより上のＹ座標での画像の接合がおかしいことなどでわかります。360°カメラなら、全体を一枚に収めることが出来るので、このような接合のおかしさは出ません(※解像度のぼやけなどは、画像の周辺部で起きます)。詳しく調べたい方は、GoogleMapのウェブサイト maps.google.co.jp/からストリートビューを表示する/mapfiles/cb/googlepano.*.swfから、画像として呼び出される/cbk?output=...を調べてみてください。

前回に引き続き、ストリートビューについてです。だいぶ、ネット上では色々な意見が出てまいりました。大きく分けて、肯定と否定があります。意識としての両者をまとめてみました。

肯定の意見では、何よりも「面白い」という意見がほとんどです。これは、GoogleMapチームが感じている面白さと同様ですね。普段、行った事の無い場所を写真でぐりぐり動かして見ることが出来る。普段ならじっくり見ることの出来ないものを見ることが出来る。「便利ではないか」という意見もあります。こちらは、これから訪問する場所の雰囲気や地形を予め知っておきたい・迷いたくないなど、地図を更に発展させた使い方や、またはカーナビゲーションの延長線上にあるのかもしれません。

否定の意見では、やはりプライバシー問題に根付いている意見が多くあります。プライバシーが推測できる情報を持った画像を、全世界の誰もが見られる状態に自主的に公開したいと思ってはいないし、勝手に撮影して削除は要連絡とは、情報管理の立場としてどうなのか、という論調のようです。犯罪に結びつくのではないかという意見もありました。

当方が最初に持った印象では、「このサービスは、日本には向いていないな」と思いました。日本に「他所様(よそさま)」という言葉があります。他人を尊重して(または関与することを良しとせず)、興味を持ったり介入をしない。人をジロジロ見ることは失礼である。他人の財布の中身をチラリと覗くことは、恥ずかしい行為である。これは、「法律」という取り決めとは関係なく、「意識の持ち方」です。例えば、偶然に見てはならないものが見える状況にあったとして、それがどんなに見たいものであっても、目をそむけて見ない。見てしまったらハッと目を伏せ、少なくとも表面上は知らん顔をするのが、生き方・行き方である。それは、「他者からどう見られるのか」という、社会の中で自分が持っている距離感に繋がっているものです。「ガンをつける」という言葉がありますが、これも、そういった距離感から存在する言葉かもしれません。

しかし反面、そういった距離の取り方や気遣いからストレスも生じるのか、一つ間違えるとエスカレートしてしまったり、他人のゴシップに対して異常なほどに興味を持つのも、また人の姿であるように思います。自分の私生活を覗かれて剥き出しにされるのは真っ平御免だが、他人の私生活は根こそぎ曝け出して知りたい。ですから、噂話は誰しも大好きで、有名人のゴシップを扱うワイドショーや写真週刊誌は、非常に人気があります。そういう興味を考えれば、面白い何かを探してストリートビューを閲覧する、これは至極当然だと思います。しかも、ネットのこちら側にそれを咎める第三者はいません。

今、ストリートビューは、この微妙なバランスの上にあります。記号である「町名・番地」「地図」よりも、「写真」は、そのままの姿を伝えるために、より多くの興味をひきつけます。「現場に行けば誰でも見られる」という考え方もありますが、現場に行くにはコストが掛かります。ですから本来は、この「興味を惹きつける」点が、ストリートビューが考えている将来的なビジネスモデルのコアになっているのかもしれません。

しかしながら、どうみても建物の関係者と考えられる人物の写真も掲載されています。おそらく、その地域に詳しい人間から面白い人物や建築物の絞込み？が進み、「ストリートビューまとめサイト」として、それらがどんどん広まっていくと考えられます。もし仮に・ですが、ストリートビューとリンクした「この写真に写っている人、もしかしたら○○の××氏と△△嬢じゃないか？」という情報が広まってしまったら、××さんと△△さんは、実際には全く別人だったとしても、ゴシップの主役に躍り出てしまいます。このように、写真という“食いつきの良い情報”と、誤った情報とが結び付けられたらどうするか？などといった客観性の存在が、ストリートビューのこれからに影響してくると思います。

Googleは、ストリートビューに関して「人のやったことは取り返しがつかない」と発言しました。当方としては、「まとめサイト」「ストリートビューにまつわる情報サイト」が出来たらどうなるか？が気になります。そのとき、なにが起こるのか。Googleは、自分達の発言を、そのまま自分達が苦々しく噛み締める状況に追い込まれるかもしれません。最近のGoogleの動き(ニュース・発言・人材流出)を見ていると、どうもかつての自由さとは異なった方向を見ているような気がしてなりません。

当方の興味だけでいうのであれば、GoogleMapに付随する「施設情報」として、ストリートビューの取材を進めて欲しかったと思っています。もしストリートビューの情報が「動物園・水族館など館内の案内」「河川敷」「登山路」「(有料の)自然公園」などだったら、間違いなくハマりますね。路地よりも、よほど珍しい風景が見られるわけですし、実際に行ってみたいという需要を喚起するかもしれないですから、ビジネスにも結び付けやすいのではないでしょうか。

最後に、「げんしけん」から、春日部姐さんのセリフを引用して締めといたします。「世の中、便利になればなるほど人間ダメになる！お前は…」

現在、2.5inchのハードディスクx2でRAID1を組んで稼動しているサーバがあるのですが、このサーバにはsmartmontools(smartd)をインストールして、ハードディスクの情報を定期的にチェックするようにしています。モニターの結果は、/var/log/messagesに書き込まれるようになっています。この結果を見てちょっと困っているのが、load_cycle_countの回数が非常に多く、健康値？が毎日ガンガン下がっているのです。このままでは、いずれエラーを吐き続けることになってしまいます。なにゆえ、この回数が多いのだろうか？対処をしなくてはなりません。

smartのload/unload cycle countは、ヘッドが円盤上からリトラクト(退避)位置に戻ったことを表わしています。この動作は、省電力機能などで行われ、普通に使っている際には発生しません。ちなみに、使っているハードディスクはHitachi HTS541260H9SA00(5K120 SATA1.5G 60GB)です。まず、当方で思ったのは、リトラクト回数が多いのは、ハードディスクに実装されているAPM(Advanced Power Management)の設定によるものかと思いまして、Feature Tools という設定ツールを使用して、省電力機能をオフにしようと考えました。しかし、家中のあらゆるPCやSATAカード、果てはSATA-IDE変換カードにまで、どんなSATAポートにつないでFeature Toolsを起動しても「APMが実装されていない」という旨のメッセージが表示されてしまいます(他の情報は見える。APMだけが「無い」と表示される)。今まで、HGSTのハードディスクを随分たくさん買ったのですが、Travelstar 5K120のSATA版だけ、APMを制御できないのです(※これ、当方の環境だけなのでしょうか？5K120のSATAでもフィーチャーツールが使えた方、もし情報をお持ちなら、宜しければメールなどで教えてください…)。

そして、更に考えてみました。このサーバのファイルシステムは、全てext3でフォーマットされています。ということは、ジャーナリングが働いているので、５秒に１回くらいはディスクへのアクセスが発生します。省電力機能などでヘッドがリトラクトする場合、ディスクへのアクセスが何分間か無かった時に行われます。このサーバでは、MySQLやらhttpdやらが常時動いていて、更にジャーナリングも行っているわけですから、基本的にディスクへの書き込みアクセスが何分間も無いような状況は考えられません。にも関わらず、なぜヘッドのロードやアンロードが起きているのか？これは、疑問のまま残ってしまいました。

そして、最後に一つ思い当たったのが、smartmontools自体の動作についてです。こちら、ソースも何も読んでいませんし(※そもそも、ATAのコマンドも知らない当方が読んでも、良くわからないだろうから読む気にもなれず)、思いつきなんですが、「もしかしたら、smartd が情報を読みにいく際に、ヘッドを退避させるコマンドを送っているのではないだろうか？」と、ふと考えたのです。現在、smartd はデフォルトの設定どおり、30分に1度、smartを読みにいきます。そこで、それを24時間に一度にしてみました。これで、ログにどういった結果が現れるのでしょうか？ こちらは、現在実験中です。何ヶ月かしたらわかると思います。

このとき、ちょっと躓いたのが、チェック間隔の設定です。/etc/rc.d/init.d/smartd に、smartをチェックするインターバル(間隔)を設定するのですが、どうもこれが反映されない。smartd_opts="--interval=86400" という記述をすれば、/etc/{default,sysconfig}/smartmontools might override だそうですから、オーバーライドされて有効になると思うのですが(※シェルスクリプトもそのようになっていますし)、might が曲者なのか？設定が有効になりませんでした。仕方が無いので、/etc/sysconfig/smartmontools のほうに -i 86400 とオプションを記述して動作させています。

※8/11日追記。いろいろ情報を漁ってみると、どうも2.5インチのハードディスクは、ノートなど動かす環境での使用が前提の為か、振動への対策などの理由で、適当な間隔？で勝手にリトラクトを行うみたいです。ブレードサーバ向けなどに、連続稼動を想定した2.5インチハードディスクという製品があるので、サーバ用途にはそちらを使った方がいいんですね。ということで、全く役に立たない記事になってしまいました。

MySQLのチューニングは、多くのデータベース開発の場で必須の知識です。が、単にmy.cnf等で設定するパラメータのチューニングだけを考えていても、必ずしも良い結果を生むとは限りません。よりパフォーマンスの高い状態でMySQLを動作させるには、稼動させるサーバの状態や、メモリ管理そのものを知っていなければならないでしょう。

ご存知の通り、MySQLは登場当初から高速な動作で高い評価を得ています。もしMySQLのパフォーマンスが悪いと感じられるのであれば、一番最初から既に間違っていると考えて構いません。CPU/メモリ/ストレージなどサーバー能力の見積り・テーブルの設計・ストレージエンジンの選定・テーブルの設計・クエリの投げ方など、これらを決めて導入・設計した企業のミス＝MySQLをうまく動かせない・と申し上げてもいいんじゃないかと思います。

それでは、MySQLのパフォーマンス向上の為に、もう少し突っ込んだチューニングのヒントは何か？を、表題にある「仮想メモリ」と絡めながら考えてみましょう。Linuxに限らず、現在主流のCPUに対応するOSは、プロセスを「仮想メモリ空間」にアドレッシングして実行しています。もし、PCに1Gのメモリしか搭載していなくても、一つのプロセスは4Gバイトのメモリ空間を独自に持っています(※32bitの場合。また、ユーザーエリアとしては4G全部使えるわけではない)。基本的に、このプロセスが持っているメモリ空間(の一部)を、実メモリに再配置して実行しているのが、現在のOSです。

間違えて思い込んでしまう一つの例として、「ハードディスクのスワップ領域にプログラムやデータを退避させ、必要になったらメモリに読み込む」ことを、仮想メモリ管理だと思ってしまうことがあります。ですが、これは仮想メモリ管理のうちの、一つの技術です。スワップが発生するのは、「稼動しているプロセス(群)のプログラムやデータが実メモリに配置されつくしてしまい、やむなくハードディスクを利用している」状態であると考えた方が、正しい理解になります。確かに、昔のOSでは常にそのように動作するものがありました(※実メモリ上にプロセスのメモリを全て配置しようとするメモリ管理のやり方)。しかし、現在の仮想メモリ管理では、メモリ活用の効率化が進み、メモリ連続性の確保など、もっと進化した方法が取り入れられています。

ですから、仮想メモリ管理を知らずにMySQLでチューニングを考えてしまうと、「あまりバッファを割り当てすぎると、すぐにページアウトしてしまってパフォーマンスが逆に落ちてしまうのではないか？」などの心配が出てきます。が、仮想メモリ管理がどのように行われているかがわかれば、バランスを考えたチューニングが可能になります。サーバの選定やパフォーマンスを最大に出すことについては、データベースの利用目的・想定されるアクセス量・MySQLを使用した上での経験則など、個人の所有するノウハウに関わってきます(ので、ここにあまり詳しく書くことは出来ません)。

先に仮想メモリの話をしましたが、実メモリ(一時記憶)にマッピングされて、実メモリだけで実行されている状態が、もっともプロセスの動作パフォーマンスがいいことは当然です。そこで、「サーバの実メモリと動作するプロセス全てを考慮して、MySQLが最も効率よく動作するメモリ配分」をロジカルに探すことが大切になります。「ハードディスクを早いものに交換しよう・RAIDを導入しよう」「CPUを高速なものにしてみよう」「メモリを増やしてみよう」などのハードウェアによるパフォーマンス向上アプローチは、確かに効果をもたらしますが、それらは、はっきりと“ハードウェアが足を引っ張っている”ことが明らかなときに実施されるべきであり、まずはMySQLが稼動しているサーバの動作状況を見直すことが、先手だと思います。

では、サーバの何を見ればいいのか？ヒントとしては、プロセスがどのようにメモリを使用しているかを調べることです。もし、MySQLのパフォーマンスが低く、尚且つMySQLが十分なメモリを使用していないのであれば、my.cnfでバッファを増やせば、パフォーマンスの底上げが出来る可能性があります。同様に、パフォーマンスが悪いにもかかわらず、MySQLに対してメモリが十分にマッピングされているのであれば、MySQLに指示しているバッファの割り当てのやり方に問題があると考えることが出来ます(※無駄なバッファに多くメモリを割り当ててあり、肝心なところにメモリが使われていない等)。

もし本当にパフォーマンスを上げようと考えるのであれば、“MySQL 高速化 チューニング”などでググったパラメータを、そのまま書き込んでも意味がありません。MySQL:サーバパラメータのチューニングのマニュアルに書かれている値や、「このパラメータには、だいたいnMバイトくらい割り当てればいいでしょう」などという情報には、自分で使う環境に関しては全く根拠がないことを、理解しなければなりません。my.cnfに設定するパラメータや値については、MySQLのshow status;コマンドで当たりを付けることが出来ますので、そこで調整を取る必要があるでしょう。

ということで、具体的に高速化をするには、それぞれの使われ方でそれぞれ最適な値がある・というまとめになってしまい、本当にMySQLの動作状態を見るなら、当方が実際に見てみるしか正解は出せないのですが、ちょっとだけ有効なヒントを出してみます。仮想メモリ管理と併せてサーバパラメータのチューニングを考えるなら、設定する値に、実メモリを意識しすぎてケチ臭い値を与えるくらいなら、ガバッと大きめの値を設定する方がまだマシなのです。もちろん、大きすぎる値はそれこそメモリのスワップアウトを起こしてパフォーマンス低下になりますが…。

MySQLのチューニングは奥が深いので、クエリキャッシュやキーバッファ・ソートバッファなどに設定する値だけを気にするのではなくて、サーバのメモリ環境全体を見通してチューニングを行う必要があります。サーバが効率的に動いている状態を見るのは、気持ちのいいものです。IT業界の悲惨な労働環境が伝聞されますが、単なるつまらない仕事にしないために、こういった点も面白がって勉強する人は貴重な存在です。そういう人を、IT業のトップはすり減らしてはいけませんね。