いつかは使うんだろうなぁという根拠のない漠然とした思いを持ちつつ、渋谷のアップルストアに仕事帰りに寄ってきました。

写真は店員さんからもらった名刺とパーソナルショッピングの案内カード。こういう名刺いいなぁ。どうしても昔のマックのロゴ(七色の横シマ模様)のイメージもあるから、ここまで単色になっていることに若干違和感もあったり。

そろそろ自分のメインとなるノートPCを決めるべく何にしようか考えていた訳ですが、もう Mac Book にしてしまえっ！と宣言してしまいます。# といっても買うのはもう少し先なのですが、、まだまだ値下がりしそうなので。

機種は下位のCPUが2GHzものでもスペックは動画や画像をほとんど扱わない自分としては十分。

今はWindows Vista を使っているのですが、やはりOS自体が重い印象だし(メモリ1GBだと絶対足りない)、フォントの見にくさ(メイリオは見やすいけど横幅取るしTPOによるかな)、設定まわりの分かりづらさ/使いづらさもあるので、使ってる上のストレスはあるかと思う。このストレスとずっと付き合う覚悟をしてお金払うのもなんだか、自分らしくないなぁと思っていたところ。

ちょうどいいタイミングで Mac Book の発売。しかも15万を切った定価は想定コスト内。重さもバッテリーもまぁこのくらいならOK。

それよりも何よりも BSD ベース(Unix)になったマックで、サーバとしていろいろ出来ることがありそうで興味津々。

年内には買う予定。あー、楽しみになってきた。

作業メモ。以下のようなことをしたいときの RedirectMatch の正規表現を忘れてしまいそうなので。

• https でアクセスにきたものを http にリダイレクトさせる
• その際、ホスト名とそれ以下の URL は保持されること

例) https://www.temp.domain.com/temp/temp.html できたものを http://www.temp.domain.com/temp/temp.html へリダイレクトさせる

• 前提環境</p>
  • 複数のホスト名をサービスしているとして、temp-ssl.conf 上、Virtual Host で設定している
  • ここでは仮に temp.domain.com に https できたものを http にリダイレクトする

• 1) /etc/httpd/conf/ or /etc/httpd/conf.d/ にある temp-ssl.conf に以下の記述を追記

サーバが複数台あるとwebのフロントだけで合計したらどれくらいのトラフィックになるかとか、運用上拡張を考慮しするやっぱり知りたくなる。Cactiでどうやるのか調べて出来たのでそのメモ。

以下は3つ以上のインターフェイスを合算する場合のカスタマイズ方法。2つインターフェイスの合算であれば途中のカスタマイズ作業は不要で5)からはじめればOK。

元ネタは Cactiの本家フォーラムから。

0) 作業前の前提条件

• 合算させたいインターフェイスを持つサーバやスイッチはすでに Cacti 上の Devices として登録済みであること
• SNMP Interface Statistics にて該当 Devices のトラフィックが Cacti にて取得できていること

1) トラフィック合計をしてくれるテンプレートを入手する

• Cacti本家フォーラムからcacti_graph_template_aggregate_2_graph.xmlをダウンロードする(ページ中央らへん)

• 直接ダウンロードはこちらを右クリックしてリンク先を保存する (いきなりクリックすると xml の中身が見えてしまいます)
• Cacti コンソール画面からインポート
• Cacti画面で、[console] – [Import/Export] – [ImportTemplates] をクリックして、ダウンロードした xml ファイルを選択して save
  • この時、Import RRA Settings は Use Defaults for this installation を選択

2) カスタマイズ用テンプレートの作成

• [console] – [Templates] – [Graph Templates] をクリックして、Aggregate 2 Graph が追加されていることを確認
• 一応、カスタマイズ用のテンプレートを別で用意するため、Aggregate 2 Graph のチェックボックスにチェックを入れて、下の Choose an action: で Duplicate を選択して go を押す
• Title Format を任意に決めて yes を押す
  • 例えばインターフェイス8つ分であれば Aggregate 8 Graph とかにする

3) カスタマイズ用 CDEFs を作成

• [console] – [Management] – [Graph Management] – [CDEFs] をクリック
• 右端の Add をクリック
• Name を任意につけて create をクリック
  • Name はトラフィックのIN/OUT用2つ作るのでわかりやすいように、Combine 8 IN とか Combine 8 OUTとかにしておく
• 続いて、CDEF Items の Add をクリック
• CDEF Items の CDEF Item Type を Custom String を選択し、下の CDEF Item Value が空白になるので、そこに記入して save を押す

ここでは逆ポーランド記法(RPN)で対象インターフェイスのトラフィックデータを加算してbit表示する式を書く。

合算させたいインターフェイスの数ごとに以下のようになる

インターフェイス数	IN側	OUT側
2	a,b,+,8,*	c,d,+,8,*
8	a,b,c,d,e,f,g,h,+,+,+,+,+,+,+,8,*	i,j,ba,bb,bc,bd,be,bf,+,+,+,+,+,+,+,8,*
14	a,b,c,d,e,f,g,h,i,j,ba,bb,bc,bd,+,+,+,+,+,+,+,+,+,+,+,+,+,8,*	be,bf,bg,bh,bi,bj,ca,cb,cc,cd,ce,cf,cg,ch,+,+,+,+,+,+,+,+,+,+,+,+,+,8,*

インターフェイス数が増えれば対応するアルファベットを増やせば適用される。アルファベットの順番は a~j まで行ったら、ba~bj、その後は ca~cj というようになるようだ。INのアルファベット順に続けてOUTのアルファベットにする。

4) Graph Templates をカスタマイズ

• 再び [console] – [Templates] – [Graph Templates] をクリックして、新しく作成された Template Title をクリック
• 合算させたいインターフェイス数に対して足りない分の Item # を IN/OUT ともに作成する
  • Graph Template Items の Add をクリックする
  • 設定内容は既存の Data Source が (traffic_in) と (traffic_out) の内容と同様にする
  • 作成された Item # を IN/OUT それぞれ Data Source (No Task):Inbound の上になるよう上向き矢印ボタンで移動させる
• Data Source が (No task):Inbound/Outbound/Current/Average/Maximum の Item # をそれぞれ変更する
  • それぞれをクリックして CDEF Function を先ほど作成した CDEFs を選択して save を押す</p>
    • 例では Combine 8 IN とした部分。IN側/OUT側を間違えないように

• Graph Item Inputs を確認</p>
  • Graph Item Inputs の Item ** が合算させたいインターフェイスの数になっているか確認</p>
    • 一通り、記載されている Graph Item Inputs の内容を確認する
    • Name は 連番で命名。FeildType は DataSource、Associated Graph Items は順番どおりの位置にチェックされているか
    • チェックが2つ付いてしまっているケースもあるので、順番どおり1つがチェックされるように変更する
  • [Graph Template] – [Upper Limit] が 100 になっているので、1Gbpsまでトラフィックが流れる場合は 1000 に変更する
  • 一通り変更が終わったら save を押す

5) グラフを作成

• [console] – [Management] – [Graph Management] をクリックして、Graph Management 右端の Add をクリック
• Selected Graph Template にて、作成した Graph Template 名を選択(例だと Aggregate 8 Graph)
• Host のプルダウンは None を選んだまま create を押す
• Supplemental Graph Template Data – Graph Item Fields にて合算させたいインターフェイスを選択する
• 選択したら最下部の save を押す
• グラフが描けていればOK
• RRDTool Command での動作確認は上部の Turn On Graph Debug Mode をクリックすれば下部に出力結果がでる

合計のみのグラフとして1つ作成させるとこんな感じに見れます。クリックするとホストのグラフと同様、weekly, monthly, yearlyのグラフが見られます。

子どもの小学校の授業参観が土曜日にあったので行ってきた。はじめて子どもが通っている学校の教室へ入る。

事前に嫁からは先生の話がが聞けない子。席を立ってしまう子がいてなかなか授業にならない状況を聞いていた。その話を聞くと原因は核家族とか子供同士の関わり方の変化とかそういうものが精神的に影響してしまっていて、それが表面化してしまっている。と思っていたが、実際授業を見てどうやら違うと思えた。

子供たちはとても素直で、元気で、正直で、うれしい時はうれしそうな顔をしていた。すごく素直でまっすぐな印象を受けた。これは自分の子供時代と共通するような、時代が過ぎてもあまり変わっていないような気がした。

授業が進む。国語の授業で2ページほどの文章を読み、情景に対してどう思ったかを子供たちに考えさせて発表させることをしていた。授業の後半で話を聞かなくなる子、席を立つ子がいた。確かにいたがそれは授業に飽きてしまっているからのように見えた。

現象の原因は授業をする立場の面白さの提供不足かと思った。

子供たちはあいまいな質問に長時間答えることにもう飽きてしまっていた。どう思うかをしつこく聞かれたところで、表現するために使える単語は多く持ってないので一文で終わってしまうのだ。

もっと彼らは表現する単語を覚えられるし、覚えたいと思っているだろう。あいまいな質問を続けるよりかは表現するための単語や漢字をもっと覚える時間に使ったほうが子ども達(聞いている側)の興味を満たしているように思えた。

この時期の子供の脳の発達はすばらしいと思う。細胞がどんどん活性化されて広がって行くこの時期に、授業の内容や先生の話が活性化するための刺激にはなっていない。

これがゆとり教育の現場かと思えた。ゆとりと聞くとネガティブさがないが、実際これはスピード感のない、刺激の少ない退屈な時間。になっていると思えた。

これは小学校の先生と生徒の関係だけではなくて、大学での講義をする人/受ける人、社会人ではのプレゼンをする人/聞く人の関係も同じだと思う。細かい単位だと会議や打合せで発言する人/聞く人の関係もそう。発表や話をする人の内容がよければ聞く人は聞いてくれる。つまらなければ聞いてくれない。大学では寝てしまうだろうし、社会人であればプレゼン中でも突っ込まれたり、結果的に顧客に認められず失注という結果になったりする。

プレゼンする人は聞いている人の時間を奪いながらも自分が主張させてもらっていることをもっと自覚したほうがいいと思っている。自分の話す言葉を考え、聞いてくれる相手に対して謙虚になり、自分の力がどこまで届くかのチャレンジだという意識を持って望むべきだと思う。

この自覚を持って話してみるだけでも、かなりの質的向上が図れると思う。

勉強がてら 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と機能的な特徴の視点で話していることがなくって捕らえ方が足りない気がしていたんだなぁ。

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