インターネットの最近のブログ記事

Google Apps(グーグルアップス)

少し前になりますが、ウチ（Life-Corporation.net）はメールサーバが無くなりました。

といってもメールを使わなくなったわけではなく、メールサーバをGoogle　Apps（グーグルアップス）へ移行しましたというお話です。

　

特に迷惑メールのフィルタリングが、いろいろ試した中では突出して精度が高く、業務効率を著しく上げてくれています。

　

その迷惑メールがふと見ると...

　

　

　

ぞろ目の「４４４４通」！

　

別に喜ぶことじゃあありませんが、なんとなくスクリーンショットっ！です。

　

この迷惑メールフィルタですが、受信から一ヶ月で自動的に削除されていきます。したがってここ一ヶ月の迷惑メール数が４４４４通ということです。

　

大体少ない時期で３０００通／月くらい、多い時期ですと５０００通／月くらいです。

　

これだけのメールを手動で振り分けていたら正直仕事になりませんし、本当にGoogle様にはお世話になってます（笑

　

それでも時々「先日の件、お願いします」みたいな"いかにも"迷惑メールによくあるような件名で迷惑メールフィルタに引っかかっちゃってるお仕事メールが無い訳ではないですが、今のところ他ではこれ以上の精度はないかなあという印象です。

　

日々進化もしていますしね。

　

しかし、メールというプラットフォームそのものを再構築しなきゃならない時期になっているのかも知れません。メールボックスが手に負えなくなっちゃってる人やメールサーバが日々警告を発しちゃってるメールサーバ管理者の人も少なくないと思います。また、くだらないメールと必要なメールを世界中の人が仕分けし、削除しているワケですから、経済損失とか計算したらたぶんとんでもないことになっていると思います。

　

そういう意味からもGoogle Waveみたいな新しいコミュニケーションの形が模索されているのではないかなあと思います。またまたGoogle様頼みなわけですが。。。

アメブロを支えるMySQL：サイバーエージェントのMySQLチューニング術
アメーバブログ（アメブロ）はサイバーエージェントが運営する無料のブログサービスである。同社のデータベースチームは急激に増加し続けるアクセスに対応し、パフォーマンスを維持するために、データベースの改善を続けてきたという。その経緯と現状が、MySQL ユーザコンファレンス 2008の場で紹介された。

昔から負荷分散に苦労してきたアメブロですが、それだけにこれまでの経緯と現状はとても気になります。

　サービスを開始した2006年9月時点では、Active-Standby構成のOracle 10g 2台のみで、MySQLは使用していなかった。これで4億PV（ページビュー）を支えていたという。

どれくらいの期間で４億PVかが気になります。
現在は

アクセスの増加に伴ってハードウェアを拡充し、現在はOracle 10g RAC 4台（Active3台-Standby1台）構成になり、MySQLはマスターに1台、スレイブに41台を導入しているとのこと。

と拡張中だそうで、そういえば現状はアメブロユーザーさんのブログを見ても”いつまで画面が出てこない→エラー画面”でイラつくことが無くなったような気もします。

将来予定している自作サーバ全面導入に向け、SSDや安価なRAIDカードでのMySQL導入テストも実施しており、セッションおよび同社ブースにおいてその結果がレポートされた。

と将来的にはハードも全サーバーを自作サーバーへする方向へと向かっているとのこと。
　
相変わらず事業的に赤字なのは脱却できていないようですが、技術的にはとっても気になるので頑張って欲しいところです。
　
　
そうそう、そういえばウチのホームページもリニューアルしてから私の自作サーバになりました。
別に大量にアクセスがあるわけでもないのでハードは特にこだわりもなく、オフィスに転がってたPCパーツを組み合わせてサーバにしたててあります。
　
今まではiDCに設置してましたが、いろいろ実験的なこともやってみたいので、今回からオフィスの一角の秘密の場所へ（笑
　
OSはFedora8、データベースはMySQL、ソフトウェアRAIDですが、意外と安定して動いています。
　
今は情報も多いので、メーカからハードとソフト（サポート？）買わなくても、意外と自作サーバーでも行けるもんです。
　
時間ができたらまたPCパーツ集めてUbuntuでも一台作ってみようと思ってます。
　
SSDも安くなってきたし、ウチも試してみたいなあ。

少し前に無線LANの暗号化方式「WEP」が一瞬で解読されるという話を書いたばかりで、

どうせならWPA2で対応していきたいところですが、現状では難しそうです。
取り急ぎWPAということになるのでしょうが、端末側が対応していない場合、WEPとの混在は困難との情報もあり、う～ん・・・。

なんて書いてたら、WPAも解読されつつあるそうです・・・。

無線暗号化技術「WPA」、一部解読される
Erik Tews氏とMartin Beck氏の2人の研究者が「Wi-Fi Protected Access（WPA）」で利用されている暗号化プロトコル「Temporal Key Integrity Protocol（TKIP）」を解読する手法を発見したという。さらには、解読にかかる時間は15分程度とのことだ。

ただ、

この手法はWiFiアダプターのデータに対してのみ有効で、PCからルータに移動するデータ保護に使われる暗号化キーが解読されたわけではない。

とのことで、今すぐに通信データが流出するという状況ではなさそうです。
でもこれから対応していくにはもはやWPA2を前提に考えていくしかなさそう。
あとはやはり有線のみか？でもこれは不便だような～。

WEPといえば、小売業TJXのデータ流出事件が有名だ。同社は店舗からのレジ情報無線転送のセキュリティ対策にWEPを利用していたが、この暗号化の脆弱性が悪用されたことから、米国市場最大のデータ流出事件につながった。

もはやWEPもWPAもセキュリティ機能としては十分な機能とは言えなさそうですが、それすらも使っていなところは結構ある。
ネットワークを流れるデータを拾うことなんて、今のご時世、そこら辺に落ちてるフリーソフト使ったってとっても簡単に・とっても分かりやすく出来ちゃう時代です（笑）
　
自社（あるいは自宅）のネットワークを見直してみるいい機会なのかも知れません。

最近は営業先などでブログが「難しくなった」と言われても、構わず書きたいことを書き進めていますが、今日はのネタは

Linuxカーネルにリモートバッファオーバーフローの脆弱性
この脆弱性は、ndiswrapperのカーネルドライバが無線ネットワークパケットを処理する際の境界エラーによって引き起こされるものだ。この脆弱性を悪用することで、過度に長いESSID（Extended Service Set ID）によってバッファオーバーフローを引き起こすことができる。

LINUX & 無線LAN？　WINDOWSな自分には関係ないと思っちゃう方がほとんどでしょうけど、LINUXは無線LANアクセスポイントなどで人知れずひっそりと走ってたりもします。
　
あなたが無線LANに接続するときにESSIDを入力していたら（ってか大体すると思いますが）接続先は大丈夫？

少し前になりますが、ウチ（Life-Corporation.net）はメールサーバが無くなりました。
　
といってもメールを使わなくなったわけではなく、メールサーバをGoogle　Apps（グーグルアップス）へ移行しましたというお話です。
　
メールサーバーはどこでも大変なトラブルの種で、毎日押し寄せる大量スパムの処理、ウィルスの拡散源、不正アクセス等など、システム管理者を悩ますネタには事欠かないものなのに、今ではビジネスの中枢にどっかと座っているのがそのメールサーバーです。
　
不正アクセスに関しては日で数万から数十万なんてのはざらで、某通信大手K●○I系列の某ホスティングが少し前に大規模障害を起こしたのも大量の不正アクセスが原因だそうです（諸事情によりウチ宛にも通知が来た）。
　
いつも新しい仕組みへ移行するのは不安が伴うものですが、Google　Appsのメールは通常通りOutLookなどでやり取りもできますし、GMailと同じインターフェースでもやり取りが可能なので少しは敷居が低かったかも知れません。
　
しかし、不測の不都合も出るかもしれないと、多少の不安を抱えつつも移行してみて感じているのは、本当にGood Value（お値打ち）だなあということ。
　
・様々な場所やPC、携帯やiPhone,windows,Mac,Linux問わず同じデータを共有管理できる
・スパムメールの排除機能が強力
・探したいメールが簡単に検索で探せる
・PCに重たいOutLookをインストールしなくても済む
　
なによりサーバー管理のトラブル対応や煩雑さから解放される気楽さは、たぶんやったことがある人以外には分からないかも知れません（笑
　
有料と無料バージョンがありますが、有料でも年間＄50です。
　
ただ、メリットばかりかというと、そうでもなくて、何かあった時はもっと深刻な問題につながりそうなところもあります。
　
何かのシステムトラブルによって、アカウントを締め出されてしまい、自社のメールにアクセスできなくなってしまったという話は時々ききますし、その時の対応は皆さんご存じのGoogle式だったようです（笑
　
そういった事態になった場合、ウチだったらどうやって対応しようかと考えると、とりあえずDNSサーバーのメールサーバーのデータ（MX：メールエクスチェンジ）を自社内のサーバーへ切り替えて対処、Googleの対応を気長に待つという形しかなさそうです。
　
ただ、いつもバックアップ用のメールサーバーを同じアカウントを設定して用意しておくというもの笑っちゃいそうな話ですし、第一うちみたいな小規模事業者だったらアカウント数もしれているので対応可能でしょうが、ある程度以上のアカウント抱えてたら無理です。
　
その場合はそれこそGoogle頼みです。
　
これはビジネスの首根っこをGoogleに掴まれているようで、しかも自社ではどうにもできない状況なわけで、それを許容するかどうかというのは経営する人の判断かなと思います。
　
　
　
　
以上は、メールサーバーに関するお話ですが、Googleカレンダーも本当に便利です。
　
例えば、ウチの会社のこのページ。
　
稼働日をApps内のグーグルカレンダーにて管理していますが、このレイヤーのみ一般開放することで、サイトに掲載したり、協業他社と共有したりも出来ちゃいます。
　
もちろん公開していない他のカレンダーもA社のBさんとプロジェクト単位のカレンダーを共有したりとかも簡単です。
　
PC、携帯、iPhone,windows,mac,linux問わず、その時手元にあるデバイスで全部管理できるので本当に便利。
　
　
　
　
docs & spretseetに関しては現状あんまり使っていません。
　
他社やお客さんからいただく原稿はほとんどがOfficeなので、やはりまだWordとExelからは離れられないかなあという感じです。
　
しかし複数アカウントで文書を共有したり、共同で編集したりというのは使いこなせれば新しい段階へ進めるのかなと。
　
　
　
最後にGoogleサイトですが、これはまだどうにも使いようがないかなあと。
 
やはり私たちCGIもPHPも使いたいですし、これはある特定の用途には使えるかも知れませんが、一般向けのWEBサイトには使いにくい。
　
まあグーグルも「Google サイトは、企業のイントラネットで使用できるほど強力である一方、家族のプライベートなウェブサイトにも簡単に使用できるほどシンプルです。」と扉に書いてるくらいなので、当たり前っていえば当たり前かも知れませんが。
　
たぶんAppsを利用しているほとんどの会社はうちと同じく
　
　メールサーバ→グーグルのメールサーバ
　WEBサーバ→自社（あるいはホスティング等）サーバ

ってな感じだと思います。
　
ということで、もしGooge Apps使いたい場合は非常時はDNSサーバーを自社でコントロールできることがまず一歩かなあと。

行動ターゲティング
Webサイトなどのユーザー（閲覧者）をその行動（ページ閲覧や検索、商品購買など）に基づいてセグメント化し、それぞれのし好やマインドに合った広告／メッセージを表示すること、またはその仕組み。
　

あなたのWEB上の動きを追跡し、あなたが反応しそうな広告を表示する行動ターゲティング広告ですが、以下の記事はドリコム社が作り、楽天などでも使われている仕組みです。
　

行動ターゲティング広告はどこまで許されるのか
　この記事で紹介されている「楽天ad4U」は、「ユーザーのブラウザー側で保有している履歴情報をもとにユーザーの嗜好を解析して、広告を配信するという仕組み」だという。これはどういうことか。筆者が調べたところ、ブラウザー側の欠陥を突くことによって閲覧履歴を取得するものであることがわかった。
　

簡単に解説すると、例えば以下のようなリンクがあります。

アマゾン
楽天
ヤフー
グーグル
このブログ
　

この中で、最近訪れたサイトと訪れていないサイトのリンクは色が違って表示されたと思います。
※記事中の実際の行動ターゲティングでは数千のリンクが（ユーザーには見えないように）埋め込まれているそうです。
　
この機能はWEBブラウザの閲覧履歴によるものなのですが、この色の違いをJavaScript（というプログラムの一種）を使って取得し→どんなカテゴリーのサイトへ頻繁に訪問しているかを分析して、最適な（？）広告を選んで表示します。
　
これは一種のスパイウェアのようにも見えますが、何かユーザーのPCに埋め込むわけでもなく、そのあたりは微妙な線。
　
また個人情報問題についても、記事中にあるように、集めたデータと個人名などが紐付くわけでもないのでクロとも言えない。
　
でも、ユーザーとしては自分の閲覧履歴を勝手に見られて、分析されているようなものなので気持ち悪いといえば気持ち悪い。
　
このブラウザの動作はバグのひとつだそうなので、いずれは修正されるものと思いますが。
　

しかし、ブラウザー側のバグを突くプログラムを配信するという手法は次の２つの点で問題があるのではないか。
 
　第一に、将来、ブラウザー側のバグが修正されたら、この広告は機能しなくなる。バグの存在を前提にしたシステムをビジネスとして展開することにリスクはないのか。
 
　このような利用が広く普及してしまうと、ブラウザー側でバグを修正する動きに対してブレーキをかけることにもなりかねない。その結果として、先に述べたブログでアダルトサイトの閲覧の有無を盗み見るような悪質な行為を防げなくなってしまう。

一つ目の「リスクはないのか？」は、やってる企業が勝手に取ってるリスクだし、楽天もドリコムも上場企業ですが、株買ってる人だって自己責任（？）なワケでまあ”勝手にどうぞ”と思います。
　
しかし、２つ目は問題かな。
　
あまりに普及して、間違ってこの手法が市民権得ちゃった日にゃあ、自分の閲覧履歴ばら撒いてることになっちゃいそうな気分です。
　
”JavaScriptをOFF”なんて今のご時世、非現実的だし、とりあえずブラウザの閲覧履歴の保存日数を”０”にでもしときますか？