Road To Nowhere

主にWebまわりのエンジニア的なお仕事に関するようなことのあれこれ。

crontabにwgetを設定したときにちょっとはまった罠

その他

バリュードメインでダイナミックDNSのIPアドレスの更新でちょっとはまったので自戒メモ。
「ダイナミックDNS設定情報」ページの「アクセス先の例」の通りのURLに対して、
wgetでアクセスするとIPアドレスを更新できるはずなので、次のようにcrontabにセット。

0 * * * * wget -O result.log http://dyn.value-domain.com/cgi-bin/dyn.fcg?d=domain.com&p=xxxxxx&h=*&i=

ところが、result.logには

status=2
Invalid Domain and Password

なんじゃいな？ということであれこれ調べたんだけど、結果、
wgetのパラメータのURLの部分を"（ダブルクオテーション）で囲んだらOK。

0 * * * * wget -O result.log "http://dyn.value-domain.com/cgi-bin/dyn.fcg?d=domain.com&p=xxxxxx&h=*&i="

result.logには

status=0
OK

切ないほどあっけないけど、けっこう時間を使ってしまった。。
同じ思いをする人がいなくなりますように。恥ずかしながらエントリー。

社内のMySQLのセミナーに参加したときのメモ

MySQL イベント

オラクルの方が社内にきてくれてセミナーをしてくださるとのことで、
内容がMySQLに関してのことだったので参加してみました。


スピーカーは梶山隆輔氏。（有名人なので名前出しちゃいます）


2時間という時間のなかで、たくさん重要な話しもあったはずですが、
特に僕の興味にひっかかった以下の内容でメモを残しておきます。

  • オラクルのMySQLに対する方針・姿勢
  • MySQL Clusterについて
  • MySQL5.5について

オラクルのMySQLに対する方針・姿勢

  • オラクルの組織のなかでMySQLは独立した組織となっている。（つまり、オラクルの元からある組織・部署から強いを干渉を受けているわけではないということと受け取った）
  • オラクルのMySQLに対する約束
    • オラクルはMySQLの開発に投資する
    • 開発だけでなく・普及・サポートも行う
    • コミュニティエディション（GPLライセンス）を継続する
  • GPLとエンタープライズ版で性能に差をつけることはせず、ユーティリティやサポートで収益化を図る。
  • MySQLのwindows版を使っているユーザーが意外に多いのでそちらにも力を入れるつもり
  • ORACLEとMySQLを一括管理できるような管理ツールを開発中

こぼれ話

  • IPAの調査によると今年日本でMySQLのユーザー数がPostgreSQLのユーザー数を初めて上回ったとのこと。MySQLの方が断然使われていると思っていたので意外だった。
  • adobeのソフトにもMySQLが組み込まれて使われているらしい。
  • オラクルが2005年にInnobaseという会社を買収。Innobaseはinnodbの開発元。オラクルのサン買収によって、MySQLの開発元とinnodbの開発元が同じ会社になったことで、議論が活発化してるとのこと。

MySQL Clusterについて

  • 元々の開発元はスウェーデンの通信機器メーカーのエリクソン。
  • シンプルな大量のトランザクションをさばくことを想定して開発されている。
  • プライマリキーを使用しないような場合はかえって遅くなる。
  • KVSのような使い方をするとGood。KVSよりも信頼性・可用性あり。

MySQL5.5について

  • innodbがデフォルト。（このinnodbはこれまでのinnodb Pluginにあたる）
  • innodbいろいろ高速化。
  • PERFORMANCE_SCHEMA
  • リカバリ性能（リカバリ時間）の向上。今までの10倍〜30倍
  • セミシンクロナス（準同期）レプリケーション。
    • これまでは非同期のレプリケーション
      • マスターはbin-logに更新情報を書き込んだら処理終了。スレーブはマスターのbin-logを読んでリレーログ（スレーブ側）に書き込み実データに反映。
      • 準同期の場合、マスターはbin-logに更新情報を書き込んだら、指定のスレーブのリレーログに書き込まれるのを待ってから、処理を終える。（スレーブのリレーログに書き込み、実データに反映されるまで待てば完全同期だがそれは意味がない）
    • データを失うリスクを軽減し、信頼性がアップ。
    • リレーログへの書き込みを待つことで若干のオーバーヘッドは発生する。
    • スレーブが複数あるとき、準同期を行うserver-idを指定することが可能。
    • binlog-formatはROWでもSTATEMENTでもOK。ただし、ROWで大量の更新があった場合は時間がかかる。


その他、MySQL Workbench 5.2 や MySQL Cluster 7.1、エンタープライズ版などの製品の説明もありました。
いやしかし社内で貴重な話しを聞くことができてとてもよかったです。
梶山さんをはじめオラクルのみなさま、ありがとうございました。

DeNA Technology Seminar #2 に行ってきた

MySQL イベント

DeNA Technology Seminar #2 を開催します - Technology of DeNA
今回のテーマはMySQLで、以下、三つのセッション。

  • Spider（斯波健徳氏）
  • MySQL handlersocket plugin（DeNA樋口氏）
  • MySQL5.5＆トラブルシューティング（nippondanji奥野氏）


この日急遽参加を決めたので、PCないしロクなメモとれず。。
詳しい内容に関してはよくまとまっている以下のエントリーや記事をどうぞ。
DeNA Technology Seminar #2 に参加してきました。 - モノノフ日記
MySQLハックの最前線が垣間見えた 「DeNA Technology Seminar #2」：CodeZine（コードジン）


以下、自分用の備忘録＆事後つけたしメモ。

  • MySQL handlersocket plugin
    • 非SQL for MySQL。SQLを使わずにMySQLのデータ（ストレージエンジン）にアクセスする。
    • これにより単純なCRUD処理を高速に行おうというもの。
    • 単純な参照クエリで効果大。また取得列が多いほうが有効。
    • 現状単純なクエリしか対応していない。
    • c++とperlのライブラリあり。DeNA技術ブログで公開予定。
    • 非SQLなら何もMySQLじゃなくKVSを使いたくなっちゃうなぁ。今のところ使う場面が思い当たらないぜよ。


えっと、まとめると

  • Spider試したいっ！
  • MySQL5.5 GA版はよこい！

ということで。


それとこれこれ。奥野氏の最新著書『エキスパートのためのMySQL運用＋管理　トラブルシューティングガイド』

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

rename() で Operation not permitted という WARNING が出た

PHP

PHP: rename - Manual
こちらファイルの移動（linuxのコマンドで言うところのmvのような操作）を行うためのPHPの関数。
このrename()を使用したところ Operation not permittedというWARNINGが発生したので、調べたことをメモ。


そもそもの話、このwarningが出てもファイルの移動自体は正常に行われていた。
じゃあなんでwarningなんて吐くの？ということでちょっと調べてみた。


ググると次のような英語のページがヒット。

http://bugs.php.net/bug.php?id=50676

rename() can only work "normally" when operating on the same volume.

同じディスクのボリュームでのみ「正常に」動くよ、ってことらしい。
確認したところ（dfコマンドで！）確かに違うボリュームへの移動しようとしてた。
まぁこれでwarningの理由はわかったんだけど、すごく気持ち悪い。。


さきほどのページでバグレポートを書いた人が

And as I pointed out in the original bug-report, the source-file actually is deleted, so there is no need for the error message.

ちゃんと動いているんだから、エラーメッセージはく必要ないじゃん！！（意訳）
って言っているのに激しく同意。だってうざいんだもん。


ちなみに
[SOLVED] PHP rename() not permitted
ここで言っているようにrename()を以下のような処理に変えておくのがきっとベスト。

if( copy('/home/frontend/uploadclip.xml', '/var/media/45ecfe0fb82968cd0244666d3b92ac4a2658d844') )
{
unlink('/home/frontend/uploadclip.xml');
}


    

    <

第三回ライブドアテクニカルセミナーに行ってきた

イベント

livedoor Techブログ : 第三回 ライブドア・テクニカルセミナーのお知らせ
こちらのライブドアテクニカルセミナーに参加してきた。
以下、めっちゃ粗いメモ。しかも途中眠くなったりしてごっそり抜け落ちている。

クラウド時代のWebストレージ/データベース戦略

  • スピーカー、池邉智洋氏、ライブドア執行役員CTO
  • 利用者から見たクラウド
    • 物理サーバ、ネットワーク意識しない
    • 高可用性
    • 柔軟課金体系
  • 提供者
    • 高価な機器に依存しない＝スケール合うと
    • 異ソース有効活用
    • 管理運用の手間の効率化
  • ライブドア的
    • 物理サーバは既にある
    • saas
    • さらに効率化したい
    • iaas paas 的なクラウド環境を自分たちで作り自分たちで使う
  • コスプレコミュニティcure面白そう
  • ライブドアでは画像アップサービスが多い
  • ライブドアが求めるストレージ
    • webサービスのメディアストレージ
    • 安価に拡張できる
    • 冗長化、高可用性
    • 実際の構成を意識したくない
  • サービス名はSTF
    • HTTPを利用したストレージサービス
  • 参考にしたのは
    • mogilefs
    • amazons3
    • rackspace cloud files
  • PROS
    • key-value
    • クライアントからは巨大なストレージプール（容量意識しない）
    • 普通のサーバで拡張可能
    • データのレプリケーション
    • apacheモジュール
  • cons
    • ファイルシステムとしてマウントできない
    • 追記できない
    • すでにあるオブジェクトは一部書き換えできない
  • design
    • bucketの概念
    • ディレクトリ概念なしキーバリュー
    • REST的なAPI
    • 認証は他のapacheモジュール
  • REST API
    • リクエスト
    • GET,PUT,DELETE
    • バケットの作成、削除
    • オブジェクトの取得、作成、更新、削除
    • レプリカの作成はヘッダで指定
  • example
  • STF internals
    • 基本戦略
      • 極力コードを書きたくない！
        • 作りながらサービスに投入
        • 大事な部分は枯れたコード
        • apacheモジュールcで実装
        • URI　mysql
        • メッセージキューで非同期処理
        • 非同期処理のワーカーはperl
    • mysql
      • テーブル一覧
        • storavge　ストレージノードマスタ
        • bucket　バケット
        • object
        • entity
    • 非同期処理
  • オープンソースで公開予定
  • 現在容量は20TBあって使用は10数TB

自分たちのサービスのために作るって言っていたのが印象的だった。
オープンソースで公開するというのもライブドアらしくていいな。

ライブドア流クラウド的サービス

後半眠気に襲われてJリーグの途中経過など見てたので、ごっそり抜けている。要復習。

livedoor Readerの新機能とは？

  • スピーカー、ma.la氏
  • 趣味で自社サービスのセキュリティ監査って！
  • サーバサイドについて
  • 180万のRSSをクロールしている
  • データ圧縮して1TB
  • 過去記事削除やってない
  • 1,3時間おきにクロール
  • パブサブハブハブはリアルタイム
  • クローラ q4mによるリレー
    • broker feed id q4m
      • cronで1分おき
    • fetcher リクエスト投げる
      • coroを浸かった並列処理
      • 同時接続数を制限
    • parser
      • 独自処理、既存モジュールはかゆいところに手が届かない
      • CPUパワーに依存、並列数は意味ない
    • updater
      • DBに書き込む
      • 記事のふりわけ　SKIP INSERT UPDATE SILENT_UPDATE
  • 高速化ノウハウ
    • 既出フラグをfeedごとにまとめた
    • ストレージとネットワークIOの節約
    • 更新されていないfeedを判別する
  • キューサーバ自作2種類
    • 自作した理由
      • 死活監視つきランダム振り分け
      • q4mのバグにあたった
      • q4mはコンパクションでパフォーマンス悪化
  • 高可用性は落ちないことより落ちても平気なように

スライド多過ぎｗｗ後半は早過ぎてとてもついていけなかった。要復習。
まぁなんせ生ma.laを見ることができたのでそれだけで満足。

ニフティクラウドの紹介と今後の展望

  • スピーカー、ニフティ山口亮介氏
  • サービス概要
    • ニフティクラウドはiaas
    • 所有から利用へ
    • 数万台規模のシステム基盤を構築済->一般の顧客へ
    • ニフティのサービスはほとんどが既にクラウドで動いている
    • オンデマンド、コントロールパネル、サーバー構成やHDD追加、削除リアルタイムで
    • システム資源のプール化、コストの最適化
    • 従量・月額、選べる料金体系、規模用途に合わせて2種類の料金プラン
    • centos5.3
    • redhat,windows準備中
  • ここまでは今でもできるぞ
    • 注意
      • 月額課金の選択は注意。日割りしてない
      • SSHキーの紛失はやばい
      • ipatables閉じすぎ注意。（なるはやでファイアーウォール提供したい）
      • 32ビット版はメモリ2GBまで
  • 内部基盤
    • とにかく疎結合
    • 規模の経済が発揮できる？
    • 技術を使い尽くせ
    • リソース基板はvmware使い尽くしている
    • サーバーはなんでもいい。
  • これからのエンハンス計画
  • CPUやメモリの増設は、一回とめる
  • コンパネは独自でフルスクラッチ

スピーカーの方がはっちゃけていて面白かった。
ニフティクラウドは今のところ企業向けのサービスという印象。

第50回PHP勉強会@関東に参加してきた

PHP イベント

第50回PHP勉強会@関東 - events.php.gr.jp
こちらの勉強会に参加してきた。
以下、粗いにもほどがあるメモ。

mixiアプリについて

  • スピーカー：weboo氏（@weboo）、mixiのなかの方
  • mixiはソーシャルグラフ（他はバーチャルグラフ）
  • mixiアプリを使いにきたユーザーが他の機能も使う。月間滞在時間が2:40から3:42に！
  • mixi Developer Center (ミクシィ デベロッパーセンター) » mixi Connect 現在一部の企業だけが使用でき、撮った写真をそのままアップロードしたりすることもできるらしい。
  • shindig=ユーザーが作成したファイルを解釈してユーザーにサービスを提供するコンテナ（違うかも？あとで調べる）
  • open social 仕様準拠API ＋ mixiアプリ専用API
  • アプリが広がるのはクチコミ。マイミクを誘う機能はあったほうがいい！
  • 最新版OAuth.php にバグがある。to_headerに指定が必要！
  • 10秒以内にレスポンスを返せるように作らないとダメ！
  • どんなアプリがヒットするか？友人と一緒に遊べないものは流行らない
    • わかりやすさ
    • ソーシャル性
    • 巻き込み性
    • 継続性
  • mixiアプリモバイルの開発で、PCからアクセス可能なsandbox準備中
  • 的ファイルを配信可能なサーバ準備中

スピーカーはmixiのなかの方なので、mixiアプリの概要をとても分かりやすく説明してくれた。
GREEの藤本さんの質問に答えづらそうにしていたのが印象的だったｗ

PHPでWEB開発を行うようにしてオープンソーシャルアプリを作る

  • スピーカー：KuniTsuji氏（@KuniTsuji）、Usagi Projectの方。
  • codeigniterでmixiアプリが作れないか？webサービスをそのままmixiアプリに移植したい。モバイルならいける！
  • セッション管理いらない！※内部的に値は保持するが
  • aタグやformタグで移動はできない。codeigniterで使う関数をカスタマイズ（anchor(),form_open）
  • セッションclass拡張、認証クラス拡張、OAuthの処理を隠す（認証クラスで使用）
  • 既存のモバイルサイトを構築するように開発してmixiアプリが動くようになった！
  • PCではどうするか・・・、難しい。表示内容、ブロック単位にPHPで出力できるようにしたほうがいい。

PHPで通常のモバイルサイトを作るようにmixiアプリを作りたいという発想が面白いなと思った。
PCはともかく、はmixiアプリモバイルの開発の敷居がかなり下がったような気がする。
アプリの話をずっとしてきて、最後にアプリは作ろうと思えば作れるが、安定して運用していくためにインフラ周りの方が重要だと言っていたのが面白かった。

運用した気になるモバイルオープンソーシャル

  • スピーカー：個々一番氏（@cocoitiban）
  • PCとモバイルの違い。絵文字、js、FireMobileSimulator最高
  • 公式と勝手のちがい。UID使わない（opensocialの仕組みで認証）、IP制限は信用ならない、最初から動線がある。
  • 注意。外部のAPIは信用しない。返事かえらない。バグもある。愛され系ゆるふわコーディング（エラーがでました→NG）
  • authoriztionヘッダとれない。BASIC認証はパースして置き換えてる。apache_request_headersを使うととれる。
  • まちつく
    • 最初普通のモバイルサイト。2009/9 mixiアプリ。2010/1 モバゲー。mixi会員250万人くらい。
    • mixiアプリリリースしたて。1日10万人ふえてく。画像生成サーバやばい。APIかえってこない。
    • 何をしたか。画像生成をキューにかきかえた。ボトルネック退治。愛され系ゆるふわコーディング。ハードウェア購入すすめる
    • パフォーマンスアップのためにしたこと
      • 100Mの回線足りない。画像サーバーをamazonS3に。
      • サーバをEC2に（今はつかってない）
      • memchached対応範囲ふやす
      • 機能を企画レベルで見直し。負荷低くなるように。
      • L７ロードバランサを増やす
      • DBマスター分割。ORMで分割。
    • 中期
      • DBサーバ分割でもきびしい→ちょっといいサーバ→解決
      • 機能改善
      • 課金等をリリース
      • 一部Q4Mへ。EC2とおわかれ、社内にもってきた方が安かった。
    • まとめると、安定志向が必要。でも新しいこともやらないと追いつかない。
  • キュー処理なに使ってる？Q4M、gearman、activeMQ
  • PHPでデーモン化。daemontool
  • ORMは使うべき。流行った場合すぐ分割できるか？トランザクションがネックになる。KVSとの透過性。
  • opensocialはトラフィック対策で甘えがゆるされない。

mixiアプリリリース時の悪戦苦闘ぶりがすごく伝わってきて面白かった。対応されたウノウのエンジニアの方にで敬意を表したい。また技術的にも非常に興味深い話がたくさん出てきた。
ORMはなんとなく遅い（SQLがチューニングされてない気がして・・・）というイメージがあるのだが、ORMで分割してパフォーマンスアップしたというのはどういうことなんだろうか？後で調べる。
opensocialではトラフィック対策では甘えがゆるされないというのは、まさにそのとおりだと思った。

最後に、、、

懇親会行きたかったなぁ。LTも聞きたかったしなぁ。残念。
会場を提供してくださったコンテンツワンさま、ありがとうございました。

モダンPHP勉強会@GREE

PHP

http://atnd.org/events/2298
こちらの勉強会に参加したときのメモ

もっと知りたい名前空間

ぜんぶ見せますSPL

こちら非常に面白かったのだけど、サンプルのコードを目で追ってばかりいたので、特にメモなし。


さてもうちょっとPHPのマニュアルを見なきゃな。
PHP: 名前空間 - Manual
PHP: SPL - Manual

追記

スピーカーのおふたりのエントリー
http://d.hatena.ne.jp/Fivestar/20091215/1260898694
http://d.hatena.ne.jp/sotarok/20091216/1260896485