勉強がてら MySQLユーザカンファレンス2008 に行ってきた。結構内容は濃かったと思うが、講演時間が50分の質問タイムなし＋資料配布なしなので、ちゃんと理解するには厳しい環境だった。当日のスライドは後日webで公開されるらしい。

Sunに買収されて有償商品の紹介が多かったような。各セッションは立ち見やキャンセル待ちが出るほどの盛況ぶりで、確かに MySQL のコアで最近な情報は本も含め出回っていない感がするので、それだけ需要があるということなのだろう。実際運用されている方の話も普段表には出ないので貴重だったかと思う。

以下、バッテリーが切れるまで取れるだけ取れたメモ。
# ノートPCのバッテリーは4時間くらい持ってくれればモバイルする意欲がもっと沸くのだが、、、
# あとは開場にコンセント用意してくれると大変ありがたい。

1日目 10/30

MySQLデータベースシステムの設計で役立つソリューション

サン・マイクロシステムズ MySQLビジネス統括本部 梶山

14:00-14:50

クラスタリング 高可用性

• 可用性＝稼働性
• 止めていい日数が多いほど可用性が高い
• 止めてもいい月間4日くらい レプリケーション

レプリケーション

• シンプルな設定、マスター=>スレーブ、多数webでの実績
• 非同期型 ほとんどの場合読み込みだけ 参照性能を上げる
• 良い構成(M:S) 1:1、1:1:N(階層的)、1:N ならOK
  • US チケットマスター 階層的な構成で構築した
• いまいちな構成 MS:MS、△構成
• ダメな構成 N:1
• 書き込み性能UPは DRBD、Active/Passiveクラスタ で冗長するケースが多い
  • スレーブサーバで障害が起きた際には別のサーバに再接続
  • テーブルごとにサーバを分けることも可能
• MySQL Proxy オープンソース
  • クライアントとサーバ間で稼働する
  • ロードバランス
  • フェールオーバー

DRBD

• 一般的なIPネットワーク上で動作
• 分散ストレージ、ネットワークRAID
• Linux上のみで利用可能
• ハートビートを飛ばしあって確認

Actve/passive

• 昔ながらの構成

MySQL Cluster

• シェアードナッシング型クラスタ
• 複数の MySQL Server にて Nodes構成、Data複数 にて Nodes 構成
• ネットワーク越しに RAID 構成しているような感じ
• Single Point of failure がない構成
• MySQL Server~DataNode 間に NDB API を設けることが出来る

トータルとして大規模構成

• データセンターごとに MySQL Clustre 同士をレプリケーション
• CGE ライセンスが必要 Standalone では構成できない

memcached 分散キャッシュ

• mixi, LiveJournal, Yahoo!, Facebook 大規模webサイトで利用
• MySQLから伽主を読み書きする
• UDFが開発中
• MySQL Enterprise でSUNが対応可能
• HP が公開しているドキュメント HP Open Source?

DRBD Plus 商用製品

• ディザスタリカバリ

セキュリティ設計

• ユーザ認証 ユーザ名/パスワードが同じでも接続元が異なれば別アカウント
• ユーザ権限 Level5 行列ごとに適用可能
• 実装済み データ暗号化、SSL、MySQL Enterprise Monitor監視、mysql_secure_installationセキュリティ強化
• 実装予定 ロールベースのアカウント管理、外部認証との連携 開発状況は http://forge.mysql.com work logにて公開

バックアップ

• MySQLバックアップ方法 Warm
• mysqldump Warm
• OSコピーコマンド Warm
• mysqlhotcopy Warm
• MySQL Administrator Warm
• レプリケーション Hot
• スナップショット Hot
• InnoDB Hot Backup(有償) Hot

NetApp

• 外部ストレージ
• スナップショットでのバックアップ

監視方式 MySQL Enterprise Monitor

• 一括監視可能なダッシュボード
• クエリーアナライザー 統計情報の分析が可能 近日リリース
  • SQL文に対して リクエスト数、レスポンス時間などwebからみれる
• エージェントインストールが必要
• アドバイザー機能あり
• 他ツールと連携 メール通知、SNMP対応

金融機関向けMySQLを活用したシステム事例紹介

野村総合研究所 情報技術本部 オープンソースソリューションセンター(OSSC) 寺田

15:00-15:50

自己紹介

• 2003年オープンソース OSSC 設立
• Linux、Tomcatなど使う MySQLパートナー契約
• 40種類のオープンソース扱う OpenStandia サービスというらしい
• 今後もオープンソースの導入が進むだろう

事例紹介 金融会社

• コスト削減でオープンソースを活用したい OSもDBまわりも
• NRI DBエンジニアが商用製品の良いと思っているところ
  • 採用実績、安定度、多くの技術者、ノウハウの展開、大規模システムでの事例
• MySQLのメリット
  • シンプルなアーキテクチャ
  • 理解しやすい、設計が容易
  • 圧倒的なコスト削減効果
• 導入前の実現可能性検証した ダメだったら Oracle にする予定
  • 性能面評価 Select(Index Scan/Full Scan),Insert
  • 機能面の評価 バックアップ、リカバリー、クラスター(冗長化)
  • 結果 耐えうると判断 導入へ
• 構成 RedHat Enterprise + MySQL、JBoss AS、Apache httpd
  • MySQL は2台構成
• 5年間コスト(初期費＋5年間保守費)で1/7へ 短期間で完了
• 顧客より
  • コスト削減はOK、性能信頼性も満たしている、より大規模システムに向けた機能には不満</p>
    • パーテション機能ない 5.1で対応予定 検証してから入れましょうにしている

冗長構成

• 非同期シングルマスタ レプリケーション
• 同期シングルマスタ 共有ディスク、商用クラスタ DRBD # 今回は商用クラスタを使った
• 同期マルチクラスタ MySQL Cluster 最近出てきた

事例紹介 サービス業L社

• プロジェクト管理システム
• 負荷分散(ロードバランサー)、DBもすべてオープンソースに出来ないか
  • CentOS, Apache, mod_jk, JBoss AS, MySQL</p>
    • JAVAを使った場合は mod_jk の高負荷時のパフォーマンスが良い
• コスト削減効果 5年間コスト 1/5になった

事例紹介 メディア企業 O社

• インターネットサイト Tomcat、MySQLを採用
• 冗長には MySQL Cluster を採用
• MySQL ServerとDataNodeのセット 2つ 障害時にはフェイルオーバして、たすき状にデータが流れる
• MySQL Cluster まだでたばかり 5.0.40以降は比較的安定している、くせがある、スケールアウトしやすい

事例紹介 金融機関 D社

• 証券のオンライントレードシステム 高い信頼性、高いピーク性
• 商用アプリケーションのサポートレベルが不満 サポート期間短い3年 バージョンアップが頻繁
• 1次切り分けは顧客実施、サポート1次窓口の質が悪かった、サポート履歴管理していない
• オープンソースでサポートの質を上げたい ソースが見れる
  • JBOSS AS、OpenStandiaで7年間サポート
• 基幹DBは Oracle、参照用で MySQL
• 顧客側から ハードのコストは下がっているがソフトのコストが負担になる
  • 台数が増えてもコストが増えない スケールメリットでやすい

2日目 10/31

ストレージエンジンまとめて概要説明

サン・マイクロシステムズ MySQL ビジネス統括本部 梶山

10:00-10:50

ストレージエンジンのメリット

• 例)メモリーストレージエンジン 処理能力を向上、Archiveストレージエンジン ディスク容量を削減
• MyISAM オーバーヘッドを配して応答性能を向上
• すべてのエンジンには外部からのアクセス方法は共通

ストレージエンジンの役割

• データレイアウト どこに格納するか
• インデックス 実装アルゴリズム
• メモリ利用 データキャッシュ、バッファリング
• トランザクション
• 同時実行 ロックの単位、排他制御

MySQL ストレージエンジン SUNがつくっているもの

• MyISAM : 標準、トランザクション対応していない、ファイルシステムの置き換え
• Falcon(Alpha) : トランザクション
• Memory : 高速ルックアップ、参照頻度が高いアプリ向け
• Archive : SELECT/INSERT のみ、ロギングや監査向け
• Merge : MySQL5.1より前のパーテショニング的機能
• Federated : 分散配置したデータに透過的にアクセス
• Custom : エンジンを開発するためのベース
• Blackhole : 書き込んだデータをすべて飲み込む dev/null 的なエンジン

サードパーティ製ストレージエンジン

• InnoDB : 標準的なトランザクションアプリケーション向け Oracleが作っている
• InfoBright : GB-TB 級データウエアハウス向け
• DB2 : IBM用

何を使っているか

• 2006年調査 エンジン名 一般ユーザ、Enterprise、OEM 割合
• MyISAM 69%, 83%, 65%
• InnoDB 60%, 79%, 54%
• Memory 10%, 18%, 9%
• Archive 5%, 6%, 1%
• Merge 3%, 12%, 3%

次 5.1

• プラグインとしてエンジンを追加できるようになる
• 出力先がログファイルではなくログテーブルにためるようになる(csvストレージエンジンで作られた) slow.log
• SQLもしくはCSV形式で出力できるようになる

ストレージエンジンごとの性能の違い

• Archive の INSERT処理能力はMyISAMの1.5倍くらい早い
• Archiveの処理能力は商用DBのテーブルの1.6倍

その他 こんなことも出来ます

• CSVストレージエンジン : CSV形式で扱う、高速データローディング、インデックス利用不可
• Bloackhole : 利用例 binログをレプリケーション多段間で受け渡すときに間に使う

コマンド

• 確認 show engines/G
• CREATE TABLE 文で指定できる ENGINE = InnoDB;
• 変更可能 ALTER TABLE t ENGINE = MEMORY;
• テーブルに設定したエンジンの確認 SHOW CREATE TABLE temp/G

MyISAM

• 1つのテーブルが3つのファイルで構成されている .frm, .MYD, .MYI
• 可搬性の高いストレージエンジン
• トランザクション非対応、テーブルレベルロック
• テーブルを圧縮可能 圧縮後は読み取り専用になる myisampack コマンド実行(基本的にMySQLを停止して実行)
• Fulltext, GISインデックスをサポート
• Concurrent Insert をサポート

InnoDB

• 表領域ファイルにテーブルデータとインデックスを格納</p>
  • テーブルごとにデータファイルの作成も可能
  • RAW デバイスを表領域として利用可能

Memory

• データおよびインデックスはメインメモリ上に配置
• ディスク上にはテーブル定義ファイルのみ存在

Federated

• 別のサーバ上のテーブルに接続するしているように見える

開発途上のエンジンもあり

• MySQL Web の wiki?に開発中のものが試せるようだ

MySQL Clusterで高性能システムを構築する際のポイント

住商情報システム 廣濱

11:00-11:50

MySQL Cluster とは

• 非共有ディスク型 特別なHWいらない
• アクティブ/アクティブ型
• 概要図より
  • アプリ~SQL Node~DataNode
  • 直接 DataNode に触れる NDB API がある
  • MySQL 上位層 NDB(NDB API)~DataNode
  • DataNode でデータの管理をしている

MySQL Clusterが利用するアプリケーション

• SQL Node経由
• NDB アプリケーション(JAVA/C++ アプリ)
  • SQLクエリを発行することは出来ないが高速

MySQL Cluster 配布形態

• MySQL Cluster 6.2.15 CGE/SE
• エディションの違い Standard Edision/Carrier Grade Edition
  • NDB Bindings なし/あり

ベンチマーク

• CGE にて 25%UP 以前のものより性能向上

ディスクテーブル

• メモリベース、ディスクベース、ディスクベース(チューニングなし) の順に
• バッファーをチューニングする場合はメモリとあまり変わらない
• DiskPageBufferMemory デフォルト64MB 可能な限り多く割り当てる

SQL Node

• 1台あたり50同時接続で最大性能等傾向は変わらない
• CPU利用率はSQLNode 4台で初めて90%近くまで上昇
  • シングルスレッドなので

InnoDBとMySQL Clusterの処理比較

• スループット MySQL Cluster CGE6.2.13 > 5.12 > InnoDB
• MySQL Cluster のほうが性能がいい
• ただし バイナリログを出すと InnoDBは倍近い性能になった

ベンチマークまとめ

• ディスクテーブルの全面的な採用はまだ早い
• DataNodeはすくなく、SQLNodeはおおく、レプリカ数は少なく、同時接続数は50くらい
  • MySQL Cluster 5.0 と同じ考え
• DataNodeはシングルスレッドなので CPUコア数を増やしても性能はのびない
  • 6.4 で改善される予定

システム構成例

• 非同期レプリケーションを SQLNode/DataNode/アプリケーション の2セット間でおこなう
• ディザスタリカバリを防ぐ 東京が落ちても大阪で提供し続ける

MySQL Clusterに適したアプリケーション

• データの見積が設計時になる程度可能なシステム
• JOINやSUB QUERYをほとんど利用しないアプリケーション
• 検索するカラムにはインデックスが張られている メモリ上に保持するので上限あり
• 単純なSQLクエリを大量に発行するアプリケーション
• 高い可用性が要求される

制限

• 設計見積よりもデータ容量が大きくなってしまったら</p>
  • MySQL Cluster だけでは難しい 止めなくてはいけない
• オンラインでマイグレーションできる 住商の製品であるらしい

まとめ

• MySQL Cluter 6.2 は使える</p>
  • 海外での事例は多数
  • 日本でも増えてきている

• 住商情報のwebで資料配布する MySQL でもwebにのせる予定

MySQLデータベースレプリケーションを理解する

Sun Microsystems Inc. ブライアン・エーカー

15:00-15:50

用語の定義

• Instance MySQLの1つのプロセス
• レプリケーションとは
  • 同じデータをもうひとつにコピーされる、自動的に non-blocking
• user applicatin – MySQL instance(binlog) – MySQL Slave Instance(Relay binlog)
  • スレーブはより長いログを持つ 迅速さではなく保持するように働く
• 5.0 Architecture
  • マスター スレーブにつなげる、マスターへつなげる
• Clustering はレプリケーションとは違う
  • レプリケーションはリアルタイムではない
  • レプリケーション自身の障害を tolerant できない
  • 2つのフェーズをコミットできない
• Cluster はMySQL Instance が Cluster とやり取りを行う
• MySQL CLuster は同時にトランザクションを行う
  • memory 上で処理する
• Read Replication Cluster
  • 非同期、書き込み
  • フェールオーバーしやすい
• Application Cluster
  • User Application — MySQL InnoDB — MySQL MYISAM が応答
• full text and Innodb
• Replicate Data to separate host
• blackhole binlog だけに残したい I/O は

以下はバッテリー切れのため手書きメモ程度。。。

</div>

近くまで行ったので、古巣の職場にちょこっとだけ寄った。インターネットバックボーン運用から離れてもう2.5年もたつのか。ずっと一緒にやってきた人と少し話したり思ったりした時のメモ。

• IPv6を結構本気で取り組んでいた</p>
  • v6フルルートは前から持っていたけど、そこから後のコア~エッジはなかったけど作ったらしい。顧客要望も出てきたらしい。
  • Windows Vista は IPv6 native なので、かなり使えるらしい
• マルチキャストもトライ中
  • 自AS内でのマルチキャストネットワークは構築した
  • マルチキャスト対応のアプリがない。。
  • AS間マルチキャスト用のプロトコルがあるらしい PIM-SM というらしい
  • クライアントレベルでチェックするときにアプリがないらしい
• 自分がいたころに苦労してひいたサイト間ダークファイバがサービスとして顧客提供されていた
• 監視ツールが SiteScope(しかもWindowsサーバ上で動いていた)のが、Nagiosに変わっていた # 偶然にも同じ
• border ルータがある程度あって、トラフィック分散できていれば Cisco GSR 級はいらないよなぁ
• ある程度バックボーンが作れてしまえば、ネットワーク的なものはそこから先あまりない
• ロードバランサとファイアウォールまで提供するサービスでもやってみたら？
  • 顧客はサーバ管理の注力できる
  • 1台/顧客だとコスト的に高くつくので、バーチャルマシン的に出来ないと # ポートがたくさんあればいいのだろうけど

久々にコアネットワークの雰囲気を感じれたな。

大事だと思ったのは運用を単にこなすのではなくて、エンジニアが発想しながら技術的なチャレンジを怠らず作り続けることかな。余計な雑音を入れずに技術的アウトプットを出すことに集中できる環境を提供する余裕が経営やマネージメント層にあるかどうかが肝なのだろう。背景には技術的なアプトプットがもたらす革新的な力を信じることだと思う。

http://japan.zdnet.com/news/ir/story/0,2000056187,20364138,00.htm

全然知らなかった。大きくなってプロフェッショナル部隊の価値が下がらなければいいけど。

行っていたら IRI で一緒だった方ともまた同じ会社になっていたかもなのかw

ネットワークエンジニアとして極める道もあったけど、インターネットサービスの立ち上げは譲れなかったから、自分にとっては結果オーライなのだろう。

今まではソフトを買うということはあまりなくフリーなものを開発者へ感謝しつつ使ってきたのだけど、この円高な時にドルで買ってみた。

Winamp は動作も早いし、mp3 の ID3タグを編集できるし細かめな設定も出来るし、再生や変換もしやすいので買ってみた。何よりも今まで長く使わせてもらった御礼みたいな感覚かな。

金額は $19.95。クレジットの換金レートがどのくらいかどうかは分からないけど、円高の今、さあいくらになるか。

スキンは日本語がきれいに表示されないものが多かったので、デフォルトクラシックで。

• 2008.12.02 追記 : クレジットの請求より 変換レート95.840円/$で、1,912円也 でした。安いなぁ。

いつものように3ヵ月ごとのチェック。

3ヶ月もたつとリテーナーに蓄積されるものが多くて、なかなか歯ブラシでは落ちない硬さになってしまっていた。特に前歯の裏と奥歯の外側に貯まりやすいので寝入りに毎食後に歯ブラシで磨いていたら力余って下のリテーナーの前歯部分に亀裂が入ってしまった。。。歯を押さえつけるには支障はないので大丈夫そうだけど、今後は気をつけなければ。。。

先生も特に大丈夫とのこと、リテーナー使って1年以内だと￥13,000で新品を作れる、それ以降は￥8,000だそうな。いずれにしても高いな。

リテーナーつけるようになって10ヶ月は経過したので、1日中から8時間くらいははずしてもいい段階に入ったとのこと。でも、4時間くらいたつとはめる時に結構きつく感じるので自分の場合は戻りやすいのだろう。あまり気にせず今までどおり常時はめるようにしようっと。

次回も3ヵ月後。

本日の清算 チェック料 ：￥5,000

# 結構トータルすると予定よりオーバーしているはず。。。総合計は一区切りしたら計算してみる予定

今は去年と打って変わって、SecondLife のイメージダウンがありメタバースはもうだめみたいな風潮がある。だた、これは今まで電通と博報堂がお金かけて SecondLife キャンペーンを打ってきたのが終わって、そのしっぺ返しがきただけでイメージの話でしかないので、正確に事態を表してないと思う。

今、メタバースサービスを運用している立場から言ってもう少しまじめに考えたいと思う。メタバースがwebの次に来るかどうかはまだよく分からないが、成熟しているwebとまだ未熟なメタバースを比較しつつメタバースの可能性をもう少し考えたい。

まず、webとメタバースは基本的特徴が全く違う。

• webは非リアルタイム
• メタバースはリアルタイム

非リアルタイムは頻度を上げればリアルタイムに近づくが、リアルタイムは非リアルタイムに近づけない。例えばブログのコメントも気付いてから書くまでが早ければ会話しているような感じになるが、その逆はない。

メタバースは基本的にログインしてその場で何が起きているかに注力されているサービスが多い。webは後から気付いたり自由なタイミングでみれたりする。そういう意味ではwebに比べればメタバースは時間的幅が非常に狭いので、生み出されるシーン(機会)が少ない状況はもともとある。ログインしたけど誰もいなかったと言うのは典型で、その瞬間にその場に誰かがいる必要がある。5分前に同じ場所周辺に誰かがいたとしてもシーンは生まれない。

サービスを測る基本的指針としては、webはページビューでメタバースはユニークログイン数になるだろう。なぜこれが指針にあるかというと、サービスに触れる機会が増えれば広告価値として高まる面を持っているから。

メタバースはもともと生み出すシーンが少ない性質なので、非リアルタイム的な機能を持たせていかないと価値が高まらないだろう。

オフラインでもフレンド申請ができる。フレンドにいつでもプレゼントが送られる。自分が作ったアイテムを今まで見てくれた人がこれだけいた。参加できなかったイベントの様子が後から見れる。など、非リアルタイムな機能をもっと充実させていくことが必要。ただ、これは難しいことではなくて最近webが当たり前のように有している機能や視点を真似すればいい。

そうすればメタバースがwebをもカバーして、ブラウザに変わりうるユーザインターフェイスになるかもしれない。

あとwebにはないメタバースの最大の特徴は生のコミュニケーションに近い臨場感を味わえることだと思う。

テキストチャットでは生み出しにくい臨場感。この点は今までにない新しい価値が出る部分で、会議のようなシーンを考えてみてもテレビ会議のようにリアルな姿が平面で見えているよりも、お互いのアバターが全身見える状態で身振り手振りを交えてテキストチャットするほうが会議に参加している感は出ると思う。

これはリアルタイムの特徴をうまく生かしつつ、コミュニケーションを重視するようなサービスの肝になるのでは。と思っている。

今まで SecondLife の創設者フィリップ・ローズデール会長や3DiのCTOの話とか聞いてきたけど、ちゃんとwebと機能的な特徴の視点で話していることがなくって捕らえ方が足りない気がしていたんだなぁ。

ご意見ある方、是非コメントください！

また何かのときに使えるかもしれないのでメモ。

ちまたにはバックアップソフトを買うだとかするようですが、rsync コマンドを使ってクーロンで動かせば基本的なことは足りてしまう。以下、バックアップサーバ(バックアップファイルをためるサーバ)にてクーロンでまわしているシェルの基本部分抜粋。

参考にしたのはいつもお世話になっているところからココ。ただ、バッククライアント側で rsync を実施しているので、こちらの方法は異なる。

動作の特徴

• バックアップサーバから rsync コマンドを使ってファイル/ディレクトリを取得</p>
  • プロトコルは ssh を使ってパスワードなし key を使う
• バックアップ先は list に記述
  • 記述例) 192.168.0.100://root/backup
• バックアップ保存先は仮で /home/backup 配下にしている
  • 最新のバックアップファイル/フォルダは new ディレクトリに保存
  • 前日以降分は biz2 で圧縮して old ディレクトリへ移動
• old ディレクトリ内の圧縮ファイルは365日経過したら削除
• 処理の詳細は /var/log/backup.log に記述
• 処理でエラーしたら root あてのメールが飛ぶ

メタバースの領域とゲームとは一般的な印象としては別物かと思うが、実際はシステム、要素、中で行われていることを見るとほぼ同じといえる。

ということで、仕事がら今年も東京ゲームショウに行ってきました。去年初めて行ったので2回目です。

着いたのがすでに16時過ぎ(17時で終わり)だったので、知り合いに会って立ち話していたら「蛍の光」が流れてきてほとんど見れなかった。。。

去年も思ったが欧米系の外人さんが多かった。逆にアジアはほとんど見かけなかった。世界的にもなかなかないゲームショウなのだろう。

しかし開場の雰囲気は去年同様、ビジネスデイといってもビジネス色はほとんどなく、熱心に体験ゲームをする人、コンパニオンを一眼レフで撮りまくる人が目立つ。ブースも何とか注目してもらって体験してもらうためにでかいスクリーン置いたり、スポーツカーを置いてみたりしている。とにかくブースが大きい。ゲームショウのブースが一番大きいのでは？

ゲームはコンシューマによって成り立っている業界なので、こういう傾向になってしまうのは分からなくもない。逆にあの場でビジネスチャンスを探している人たちにとっては効果薄な印象がある。

確かに最大級のイベントなのだが、客観的に見ればごく限られた日程と場所で行われる小宇宙でしかなくてそこで見せる意味はどれくらいあるのだろうとふと思う。では、代わりになるものは、、、と考えてそれがネットであったとしても今のネットではそこまで能動的なアプローチはしにくいので短期間では難しいなぁ。でも、ネットの可能性は色あせることなく今も存在する。

そうか、ネットで何かをアピールしたい場合、短期的なリスクを考えて怖くなっても、信じきって進む覚悟が必要なのか。信じるものとしては「良いものはみんな使ってくれるはず」というシンプルな解なのかもしれない。

だから怖くなってしまうとCMとか雑誌の取材とかに走りがちになるのか。

最近、ネットの可能性が最も大きいと思いつつも、既存のCMや新聞の影響力を感じていたので少し考えられて良かった。

09年4月くらいだったかメールサーバを構築した際にメールプロバイダ(メールアカウントを発行してサービスしているところ)ごとにだいぶメールの扱い方が違ったのでメモ。すでに忘れている部分もありうろ覚えだけど書いてみる。現在はすでに対応内容は変わっている可能性があるかもしれない。

大体やってみたところ以下の項目をみつつSPAM扱いにするなり、受信拒否なりしているようだ。項目は上から順番に重複させて設定していく。例えば項目3は項目1と2を実施してある状態に3を行っている。

1. メールのヘッダに送信元のサーバ名があるかどうか
2. メールヘッダの送信元のサーバ名の逆引きができるかどうか
   • このとき送信元IPアドレスはバックアップ回線の他プロバイダから送信
3. メールヘッダの送信元のサーバ名の逆引きされたIPアドレスが、実際の送信元IPアドレスブロックと同じかどうか
4. DNS 上で SPF に設定されているメールサーバかどうか

アカウントは Gmail、Yahoo!Japanメール、MSN(hotmail)、WADAX の4つで試してみた。

受信できたら○。SPAMフォルダに入れられたら SPAM、受信すらできなかったら×

	Gmail	Yahoo!Japanメール	MSN(hotmail)	WADAX
1	○	×	×	×
2	○	×	×	×
3	○	SPAM	×	×
4	○	○	SPAM	○

MSNは結局最後までちゃんと受信できず。ウワサではこんだけウチのメールサーバはちゃんと設定してるので、受け取るようにしてくださいね。のようなメールを出して相当時間がたってから対応してくれた話もあり。

GmailはユーザのSPAM申告によって出来上がったブラックリストに引っかかるものはSPAMフォルダに入るようになるが、それ以外の要因は全く関係なく受信してくれる。ある意味良く分からない色々なこねくり回した条件をもとにメール拒否されるよりかは、シンプルで分かりやすい。

ネットワーク環境はさておき、メールサーバとしての動作確認をまず純粋に行いたい場合は Gmail に出してみる。ということは覚えておいて損はないかと思う。

以前使っていた audio-technica のインナーイヤーヘッドホンはケーブル分岐部分の中の断線で片耳が聞こえなくなってしまったので、新しいのを買う。またすぐ使えなくなっても悲しいので同じくらいの値段の3000円以下くらいで、ビックカメラで audio-technica 内だとコレだったので決め。

ケーブル分岐部分に負荷がかからないためにかスライダーがついて改良されていた。10時間くらいエージングかけて出勤時にいざ聞いてみる。ん？なんだこの音？以前に比べて中低音が聞こえなくって、高音の高めのところがかなり目立つ。音楽で言うとベース音とヴォーカルがひかえめで、ドラムのハイハットがやたら目立って耳につく。ずっと聞いていると疲れてきた。。。価格.comのレビューでも泣いている人が多いようだ。

でも、毎日使いたいので何とか改善を試みる。エージングを増やしてもあまり変わらないと思うし、これはスピーカーの特性だと思うけど、ここまで以前のものと変えるのもおかしい。。。ふと見るとイヤービース(耳栓の部分)の形状が以前と違うような。以前のイヤーピースの予備が残っていたので、並べて比べてみる。

• 今回

• 前回

今回の方が耳に入る部分が長く、穴の大きさも小さくなっている。画像だと分からないけど触ってみると今回の方が厚さがあって硬めになっている。

前回のイヤーピースに付け替えて聞いてみる。ん～、いい感じ。これこれ、低音がしっかり出ていて中音も豊かに高音のとんがりもなくなった。よしよし、これでいけそうだ。

理屈で考えると、

• 耳に入る部分が長くなるとイヤホンと耳の中の出っ張りまでの距離がなくなって、耳の中で音が響きにくくなって低音が収まって、逆に高音の高い方はこういう状況でも通りやすので目立つ
• 音の周波数が低い方はスピーカーの面積が大きいほど出る。なので、穴を小さくしてしまうと低音が出てこない

大学時代に習った音響工学。あったなぁ。

もしコレを買って失敗したと思っている方。前回のスペアイヤーピース(ER-CK5)に付け替えることをお勧めします。一応サイズを指定しなきゃいけないみたいですが、買えるみたいです。

良き音楽ライフを！