本を読む

読書やコンピュータなどに関するメモ

OSC 2011.DBに行ってきた

 オープンソースカンファレンスのDB版「オープンソースカンファレンス2011.DB」に行ってきました。MySQL・PostgreSQL・Firebirdの3つを中心に、なぜかHadoopも混ざりながら、青山のオラクルでセミナー形式で開かれました。

 以下、メモほぼそのまま。

PostgreSQL 9.1 and more(永安悟史・藤井雅雄)

(遅刻のため永安氏のパートをほぼ聴けず。残念)
レプリケーションの話(藤井氏)
  • 9.2は来年夏ごろリリース予定
  • カスケードレプリケーション
    • スレーブ→スレーブ
  • バックアップ
    • pg_basebackupコマンド
    • スレーブからでも
  • pg_receivexlog
    • マスターからWALを受信し続けるクライアントツール
    • PosgreSQLサーバーを起動していなくてよい
    • WALの二重化など
  • WEB+DB vol.65、PostgreSQL 9.1の特集
  • 日経SYSTEMS 2011/11「こちら検証ラボ」
  • Q: 最近の面白い事例
    • A: いろいろなところで使われている
    • これから面白いのは、NoSQLとの組みあわせか
    • 知っている例では、メジャーなパッケージソフト、クラウド化
      • テーブルスペース1万、スキーマ1万とか

OSSDB MySQL(とみたまさひろ・須藤巧平)

とみた氏
  • MySQLはOSS
    • 「真のOSSとはいえない(キリッ」発言w
    • 買収されても大丈夫w
  • MySQL 5.5からcmake
  • 開発版 5.6
    • InnoDBオプティマイザ統計情報の永続化
      • 統計情報をシャットダウン時にディスクに保存
    • デッドロックをエラーログに出力
      • 明示的なパーティション選択
    • 特定のパーティションからselectなど
    • binlogの容量削減
      • レプリケーション情報
    • 遅延レプリケーション
      • CHANGE MASTER TO MASTER_DELAY=n
      • 操作ミス等でのデータ喪失に対応できる
  • 開発版
    • http://labs.mysql.com/
    • InnoDB全文検索
      • 日本語非対応
    • InoDB memcachedインターフェイス
      • InnoDBにMemcachedプロトコルでアクセス
  • マルチストレージエンジン
    • テーブル単位
  • Q4M
    • MySQLでメッセージキュー
    • ENGINE=queue
  • Spider
    • sharding
  • vertical Partitioning
        • カラム単位で縦分割
  • Groonga
    • 全文検索
須藤氏
  • groongaストレージエンジン
  • 高速な全文検索
  • 高速な位置情報検索
  • リアルタイム更新
    • 追加が高速
      • TwitterのTweetを追加して検索、など
    • 参照ロックフリー
      • 検索していても更新できる
  • トランザクションなし
    • groongaストレージエンジン+InnoDBで
      • 全文検索を横取り
      • 検索はgroongaストレージエンジンに近い
      • 更新速度はInnoDBぐらいになってしまう
  • ALTER TABLE未サポート
    • 次リリースで
  • MariaDBにバンドルされることになった(拍手)
  • Q: MySQLはCHECK制約がない。今後は
    • A: 把握していない。Oracleさんなら知っているかも

Windowsで使うFirebird(木村明治と愉快な仲間)

  • 木村氏と林氏の漫才形式
  • なりたちからしてWindowsに強い
  • DBとは
  • データ保存をすると
    • 最初はテキストファイル
    • データが増えると遅くなる
    • 検索
    • 排他制御
  • ORDB(Object oriented database)
    • PostgreSQLも実はORDB
      • パーティショニングは実は表の継承でやっている
    • まあ聞かなくなった
  • Firefoxと間違われるw
  • WorldWideではMySQL vs Firebird
  • Interbase 6がオープンソースになってFirebirdに
  • アプリケーションインターフェイス
    • JDBC
    • Borland
      • Delphi
    • Perl、PHP、Pyuthon、Ruby
    • ODBC
    • .NET Provider
  • アプリケーション組み込み(インプロセスライブラリ)
    • 同じ製品でCSと組み込みがある
      • MySQLも
    • DBファイルが単一ファイル構成
      • Sybase Anywareも
  • プロセスモデル、スレッドモデル、インプロセス
    • 組み込みのときは、アプリケーションインターフェイスはそれ用のライブラリで
  • InterBase 6.0が一時OSSになったときにブランチ
    • それぞれ発展
    • 主なツールは両対応
  • 現在2.5.1
    • 3.0がα版
      • プロセスモデルをやめてスレッドに一本化?
      • DBごとにセキュリティのDBを持てる
  • .NET Providerが熱い
    • .NETはDelphiの後継と考える人も
  • FLAP(Firebird + Linux + Apache + PHP)
  • パッケージにしたときにライセンス料が発生しない
  • ブラジルではFirebird専門のカンファレンスに大勢集まる

ioDriveとInfiniBandを利用したDRBDによるリアルタイムレプリケーション(サードウェア岩崎・滝澤)

  • DRBD
    • ネットワーク越しのミラーリング
    • ブロックデバイスを複製
    • バックグラウンドでの差分同期も
  • ネットワークのレイテンシよりHDDが遅かったという例も
  • Fusion-IO ioDrive
    • PCI Express直接接続
    • DBなど
  • InfiniBand
    • HPCで使われてきた
    • 低レイテンシ
    • 広帯域
    • IP over IB
  • 検証
    • SAS HDD、SATA SSD、ioDriveの3つを比較
      • ライトバックキャッシュの有効無効も
    • HP Proliantサーバー
    • RHEL 6.1
    • DRBD 8.3.11(検証当時の最新版)
    • PostgreSQL 8.4.7
  • HDはInfiniBandでDRBDしてもほぼ変わらない
  • ioDriveで10%程度の低下
  • SSDをRAID0にしてもスループットがあまり速くならなかった
  • IB + ioDrive + DRBD
    • スケールアウトではなくスケールアップによるトータルコストの削減
    • 安全性の高い高速データベース
  • Q: IBは直接? スイッチで?
    • A: 直接つないだ。OpenSMというデーモンを使った。
    • カードが安くなっているので、コストメリットがある構成。
    • IBスイッチが8ポートで20~30万
  • Q: ファイルシステムは
    • A: ext4。デフォルトの状態で、ファイルシステムのチューニングはしていない
  • Q: IBの帯域はどのぐらい使ったか
    • A: CPUに依存する。この環境では10GBぐらいしか出ない。
    • 違うマシンで15~16出た。
    • CPUをふりきった。CPUがボトルネック
  • Q: ioDriveの書き込み回数の制限をDRBDで回避? でも両方同じ制限?
    • A: どのぐらいもつかFusion-IOに聞いた。1日4GBの書き込みで10年以上、というデータがあるらしい。
    • 書き込み上限に達した場合については検証していない
  • Q: HDD + Ethernet
    • A: 理論上125MB/s、イーサネットがボトルネック
    • 10G、SATA+RAID 0でディスクがボトルネック
    • IBにした理由は、10Gで速度が出なかったから
    • openibdは起動するとカーネルパラメータ(送受信ウィンドウとか)を勝手にチューニングしてくれる

PostgreSQL 9.1とpgpool-II 3.1(SRA OSS 北川俊広)

  • pgpool-II
    • アプリケーションとPostgreSQLの間
    • slony-I(トリガーベース)と併用可能
  • アプリケーションサーバーと同じマシンに同居させることが多い
  • アプリにはPostgreSQLとして見える。意識しない
  • 遅延を考慮したロードバランス
    • delay_thresholdの値を超えたホットスタンバイサーバーには参照クエリを投げない
      • 古いデータが返るのを防ぐ
    • トランザクション内の参照クエリもロードバランス
    • トランザクション内で更新クエリが発行されたら以後の参照クエリはプライマリに
  • 自動フェイルオーバー
    • ダウンを検出してフェイルオーバー
      • クエリを投げたとき
    • 定期的なヘルスチェック
    • フェイルオーバー時にプライマリに昇格させる
      • フェイルオーバー時に実行するコマンドを登録できるので、そこで指定
    • オンラインリカバリ
      • PostgreSQLのリカバリ機能をpgpoolで実行
  • pgpool-II 3.1 変更点
    • 2011年9月リリース
    • insert_lockのロック方法が変更に
      • ~2.3:テーブルロック
      • 3.0:シーケンステーブルの行をロック
        • vacuumなどと競合しない
      • 3.1:insert_lockテーブルの行をロック
        • シーケンステーブルのロックがとれなくなったため
        • このテーブルを作っていないと、~2.3と同じに
    • backend_socket_dirの廃止
    • pgpool_walrecruning()の廃止
    • pool_nodesにノードIDの列を追加
    • nextval()とsetval()がblack_function_list/white_function_listの設定に従うように
      • 排他的な指定なので、片方が空になる
  • 新機能
    • syslog対応
      • ログ機能がなかった
    • application_nameに対応
    • relcache_expireパラメータ
      • PostgreSQLのシステムカタログを調べたキャッシュの有効期限
      • 従来は無期限
    • follow_master_commandパラメータ
      • フェイルオーバー時に実行するコマンドの後に実行するコマンドを指定
    • pcp_promote_nodeコマンド
      • プライマリノードを手動で変更
    • pcp_pool_statusコマンド
      • SHOW pool_statusのコマンド版
    • health_check_passwordパラメータを追加
      • が、未実装
    • pgpool_admin関数
      • SQLから
    • UNLOGGEDテーブルに対応
      • プライマリのみ
    • 中文のドキュメント
    • backend_flagNパラメータを追加
      • フェイルオーバーしないノードの指定
      • コネクションプーリングだけ使っている場合など

OSS「超」入門(野村総研 寺田雄一)

  • 商用ソフトウェアは使用許諾にお金を払う
    • ベンダーが修正
  • OSSもライセンスがある
  • コミュニティ
    • 開発コミュニティ
    • ユーザーコミュニティ
  • 企業がコミュニティを主導する場合も
  • 2007年度のOSS活用ITソリューション規模は1兆円を超えた
    • 基幹系システムでの利用がリード
  • 導入ポイント:価格
  • 心配点:サポート
  • オープンソースの誤解
    • 品質が悪い?
      • ものにもよるが、大規模システムへの導入自責も豊富
    • 高くつく?
      • 慣れの問題
    • エンジニアがいない?
    • 自己責任?
      • 商用サービスもある
  • オープンソースビジネス推進協議会(OBCI)

分散処理基盤Hadoopの概要と動向を紹介(濱野賢一朗)

  • 日本Hadoopユーザー会
  • Hadoop Conference Japan
  • 「1ペタバイトのデータのインデックスを作る」
    • 耐えうるフレームワークがなかった
    • MapReduce
  • 大量のデータを読み込むのが大変
    • →横に並べて並列に読む
    • HDFS
  • データを分散したまま移動せずに処理する
    • データのローカリティをいかす
    • Map Reduce Framework
  • 大量データに特化したバッチ処理システム
  • きれいに数千台までスケールする
  • HDFS
    • 大きなファイルを分割
      • 64MB単位
  • MapReduce
    • 分散処理の難しさ
    • 個別対応が多い
      • どう分割するか、どう束ねるか、失敗をどうリカバリするか
    • フレームワークでパターンを作ることで簡単にする
    • map、shuffle、reduce
      • mapでデータを塗り分ける
      • shuffleで塗り分けたデータごとにまとめる
      • reduceで束ねる
  • Hadoopのエコシステムが魅力のひとつ
    • Pig
    • Hive
    • Mahout
    • HBase
    • ZooKeeper
  • RDB vs Hadoop
    • RDB
      • 管理する
      • 正規化
      • 一度に走査する単位を小さくする
      • 低レイテンシ重視
    • Hadoop
      • 「管理」しない
      • 非正規化
      • 一度に走査する単位を大きくする
      • スループット重視
  • 事例
    • Yahoo
      • 検索インデックス、迷惑メールフィルタのデータ作成
    • 楽天
      • レコメンデーション
    • DeNA
      • ゲーム中の行動履歴分析
    • VISA
      • カードの不正利用をあぶり出すモデルを生成
    • 国会図書館
      • 書誌データから検索エンジンSolr用のインデックスを生成
  • 最近のトピック
    • MapReduce 2.0
      • マスターサーバーの構成の変更
        • 1万台ぐらいスケールするように
        • Yahoo!のオーダー
      • MPI等にも対応
    • 機械学習
    • ベンダーによるHadoop拡張
      • Hadoop API互換のプロプラ製品もあるので注意
  • 来週NYでHadoop World

パネルディスカッション

第1部:コミュニティ最新情報(木村明治、濱野賢一朗、とみたまさひろ、永安悟史)
  • 永安:PostgreSQL(PostgreSQLユーザ会)
    • 情報提供
      • オフィシャルマニュアル、サイト
    • 人を育てる
      • セミナー、勉強会
    • 人をつなぐ
      • 飲み会
  • とみた:MySQL(MYNA)
    • 発足当時:MySQLの日本語化、普及、ユーザーのコミュニケーション
    • 最初の2つは達成できたので飲み会w
    • 技術面はOracleが
  • 濱野:Hadoop(Hadoopユーザー会)
    • 勉強会は草の根でやれるが、一同に会す場として
    • Hadoop Conference Japan 2011 Fall
      • 1178名
    • まだHadoopを使ったことがない人が過半数
      • 情報収集
  • 木村:Firebird(Firebirdユーザー会)
    • MLへの質問は、木村さんか林さんが答えている
    • レベルがいろいろあって勉強会のテーマが難しい
  • 赤井:勉強会に非常に人が集まり、コミュニティは人が減っている
  • 永安:ユーザー会から見て、どういうところで情報を入手しているかが見えづらくなっている
    • ユーザー会で勉強会を開催することで、世の中の動きについていく
  • 木村:PostgreSQLやMySQLは新版が出てネタがある
    • Firebirdは地味な更新ぐらい。古いバージョンを使い続けている人も多い
  • とみた:MLはメールアドレスを晒さないと質問できないのがハードルが高いのかも
    • アーカイブから自分の名前を消してくれ、という依頼もある
    • mysql casualという勉強会も人気
  • 濱野:昔からやっている人はMLでいい
    • 若い人は情報交換のやりかたが違っているので、頭を柔らかくしないとリーチできない
    • TwitterなりSNSなり掲示板なりとつなぐ?
    • 情報が分散している
    • HadoopはTwitterでの議論が多いが、集約されない
  • 永安:情報元のアンケートをとった
    • 試行錯誤している
  • 会場:海外との比較。日本は情報収集力が落ちてる?
  • とみた:ぜんぜんそんなことはない。
    • すでに普及している。Oracleが情報を出している
    • ユーザー会に頼らなくてもよくなっただけではないか
  • 濱野:世界のHadoopに関するTweet、言語別
    • 英語に続いて日本語が2位
    • 英語圏の人がHadoopのTweetを収集していて、日本語が多数混じっていて困る、という声もw
    • 日本に情報があふれている
  • あかい:USでは10年前に草の根勉強会が絶滅した
  • 濱野:SFではまた最近、飲みながら開発するような集まりが盛り上がってる
  • 木村:Firebirdは、英語、ロシア語、ポルトガル語
    • Google Translatorを使って日本語ブログも読んでるらしい
    • 海外では、ワールドワイドで1つのコミュニティ
  • あかい:ほかのコミュニティで参考になること
  • 濱野:できたばかりなので、いままであるすべてが勉強になる
    • 話題が落ちついてからのふるまいをどうするか
  • 木村:MySQLは技術がわかる人が多くていい
    • PostgreSQLは土地ごとに詳しい人がいる。MySQLもそれはない
  • 永安:商用DBのコミュニティいいなと思う(DB2、SQL Database、Oracle)。継続的に開催
    • LL系コミュニティは、企画力も動員力もすごい
  • とみた:PostgreSQLの組織力
    • MYNAでは、Oracleでやらないような勉強会をやりたい
      • 初級とか、ニッチなのとか
  • あかい:長い歴史のあるコミュニティの勉強会は、対象にあてはまる人が限られることがある
  • 永安:意識してレベル別の勉強会を開いている
    • 初心者向けも
  • 濱野:Hadoopは二分されている
    • マニアックなものは放っておいても草の根で勉強会ができる
      • まだHadoopは開発者と乖離していないので、コアな情報も得られる
    • そのため大規模なイベントは幅広くリーチするような方向で
    • おじさんばかりにならないように
      • 若者の集まりを応援するか、あるいはそちらにもリーチするか
  • とみた:若い人は、MySQL単体というよりは、インフラ勉強会などに集まっている
第2部:人材育成、エンタープライズ(梶山隆輔、濱野賢一朗、永安悟史、松田神一)
  • 梶山:MySQLビジネス順調
    • 課題。かつては日本語情報がない。
    • 最近は日本語情報が十分になってきたので、若い人が最新情報を英語で取りにいくようになってきた
  • 永安:PostgreSQLが初期に普及したのは日本語情報があったから
    • 仕事は生半可な知識ではできない
  • 梶山:SIerがユーザーに言われてOSSを導入することになり、あわてて勉強するケースもある
  • あかい:企業でOSS DBを使う課題
  • 濱野:自社の場合。PostgreSQL。コアな人材は集められている。
    • しかし、現場のエンジニアのすそ野はまだ追いついていない
  • 松田:LPICを10年前にはじめた
    • 資格試験。エンジニアの動機づけに
    • Linuxの次にDB
  • あかい:何を学ぶか
  • 梶山:基本は変わらない。
    • 高可用性、バックアップ・リカバリ、運用監視など5つ
    • どのDBでも共通
  • あかい:育てられた経験から
  • 永安:DBは本質はずっといっしょ
    • 応用がきく
    • 自分のスキルをスケールさせるのは無理
      • 10人を育てるにはどうするか、を意識する必要
    • OSSは職人気質の人が多く、体系的に人を育てるのが好きじゃない人も多いが、必要
  • あかい:学校の教育は役に立つか、企業の現場でおぼえるか
  • 濱野:いつも対立する議論
    • 両方とも重要
      • 尖ったエンジニアには資格試験は十分じゃないと言われるが、必要ではある
      • 現場経験だけだと使ってないものを知らなかったりして偏る
    • 資格試験勉強をすると「こんなの使わない」という知識も出てくるが、後々で役に立ったりする。自分の世界を広げる
  • あかい:資格やトレーニングコースの意図
  • 梶山:細かいオプションやコマンドを出してどうする、という声もあるが、それを知ったことでシェルスクリプトを組んで処理しなくてもよくなることがある
  • あかい:OSS DB試験を始めた背景
  • 松田:Linuxの用途としてWebサーバーが多く、バックにDBがある
    • OSSエンジニアを育てていく
  • 会場:DBだけではなくてシステム全体の知識が必要ではないか
  • 永安:そう思う。
    • DBエンジニアはアプリもハードも知る必要がある
    • 運用も。縦も横も
    • DBエンジニアから入ると、すべてにふれる
    • 上から下まで設計できる人が揃っていない
    • いかにそのような人を育て、見付けていくか
  • 梶山:OSSだけではない、という結論に
    • 組み合わせ、やりたい
  • 濱野:組みあわせは無数にできるが、定番の組み合わせにはノウハウがある
    • Webの3層システムのタイムアウト設定とか
      • そういうのを研修しているところはある。が、資格にはしづらい
    • OSSならではの目利き
      • いろいろな経験をしないと目利きできない
  • 松田:パーツは教育でできるが、組みあわせは教育では限界がある。そこはOJTで
  • あかい:運用系の知識や情報
  • 梶山:MySQLは経験のある人間(Nippondanji氏)がセミナーや書籍で啓蒙している
  • 永安:運用系の知識がないのが問題と考えていた
    • PostgreSQLのエンジニアと話せるだけの知識を
    • OSSの人は開発や先端が好きな人が多い
  • あかい:商用DBからOSS DBへ移るときの抵抗感、障害
  • 松田:商用のほうが機能が多く、かゆいところに手がとどく
    • が、機能の差が小さくなってきている
  • 永安:いちばん足りないのはプリセールスではないか
    • 商用の世界ではリスクを取って「できます」と言い切る人がいる
  • 濱野:既存のシステムの移行は現実的ではない
    • 新規システム
    • OSSにはキラキラしたものが少ない
      • 細かい機能なり、プリセールスのウリなり
    • 頭を使えば同じことはできる
      • 機能の組みあわせ
    • 「新規のシステムはできるだけOSSでやろう」といういきごみが重要ではないか
  • 梶山:MySQLの場合、移行より、ど新規案件
    • それまでになかったもの、エンタープライズでは考えられないスケール
    • Facebook、携帯インフラ
    • エンプラの経験や知識が足かせになることも
    • 考え方を変える必要
      • が、人間なかなか変わらない
  • あかい:Twitterからの意見。OSSはマーケが弱い?
  • 永安:ああいうことができればいいなと商用DBを見ている
    • 製品ブランドの付いた会社、資本力
    • 製品の勉強会を開いたり
    • ぶっちゃけ、技術者中心のコミュニティなので、マーケティングは弱い
  • あかい:MySQLは。Oracleは置いておいて
  • 梶山:OSSは商用ソフトからはありえないマーケティング
    • むしろ武器
    • 活用できていないのかも

LT:MySQLの文字コード(とみたまさひろ)

  • charset
    • 文字セット、文字コード
  • collation
    • 文字の照合規則
    • 大文字小文字を区別するか
    • 全角・半角、ひらがな・カタカナ、濁音
  • サーバー変数
  • はまりたくなかったらUTF-8で統一
  • DBのcharset、tableのcharset、カラムのcharset
  • 接続のcharset
  • 文字化け
    • 文字セットにない文字
      • "?" という文字でDBに入る
    • 接続で"?"に
      • 表示が化けるがDBはママ
  • 混在する理由
    • インデックスサイズ
  • ASCIIとUTF-8との比較
    • 照合順序

LT:データベースのフロントエンドにLibreOffice/OpenOffice.orgのBaseを(鎌滝)

  • LibO/OOo:オフィススイート
    • DBのBaseもある
  • 標準DB
    • HSQLDB
  • 外部DB
    • MySQL
    • PostgreSQL
    • Firebird
    • SQL Server
    • DB2
    • Oracle DB
  • ビジネスでHSQLDBは使えない
    • パフォーマンス
    • 複数人で共有できない
  • 外部DB
  • Baseのフォームが使いやすいので活用を
  • 専用のSDBCドライバがあるもの
    • MySQL
    • PostgreSQL
  • JDBC/ODBCを利用できるもの
    • unixodbc
  • OOoユーザー会アンケートをBaseで作って、展示を兼ねて毎回ブースに置いている

LT:オープンソースDBカンファレンス2006@ドイツ(木村明治)

  • International PHP 2006 Conferenceで併催
    • 行ってきた
  • ドイツのDBといえば
    • 「ドイツ鉄道」w

LT:「オープンソースデータベース標準教科書」開発秘話(宮原徹)

  • 専門学校向けの教科書に
    • 内容面
    • 講義のスケジュール面
  • 標準教科書シリーズ
    • クリエイティブコモンズで配布
  • 完全初心者対応
  • 途中で挫折しないように、量を絞る
    • まずは最初の達成感
  • 実行例をコピペするだけで実行できる
  • PDFとEPUB
    • 達人出版会
  • EPUBのデモにも最適?
  • 今回は正規化あきらめた
    • 次は設計編?

LT:商用ソフトウェアで構築・運用する高可用性PostgreSQLシステム(MKTインターナショナル あかいまこと)

  • Insight Outイベントでアンケート
    • 今後知りたいこと
      • HA、物理設計、運用、バックアップ・リカバリー
  • PostgreSQLのビジネスを立ち上げようとしてきた
  • 企業向けシステムはすべてOSSにする必要はない
    • 組み合わせ構成
  • 経験として、サーバーよりもストレージにふりまわされた
    • 物理設計
  • コンサル提供できないか
  • ハンズオンも
  • 日本HP・アップタイムテクノロジーズ・MKTインターナショナルで、トレーニングコースを提供する

LT:日本PostgreSQLユーザ会活動紹介(永安悟史)

  • We Need you.
  • 勉強会
    • ハンズオン形式も
  • 翻訳マニュアル
  • Let's Postgres
    • 技術系の記事をWebで提供
  • ニュースレターを毎月配信中
    • ユーザー会のWeb会員
  • Facebookページ
  • Twitter @PosgrgreSQL_JP
  • 開発に参加
  • 翻訳に参加
  • 盛り上げに参加
    • 知人の紹介で参加する人が多い

コメント

読書量がすごいですね!

私も本をたくさん読むほうですが、とんでもない読書量ですね!感服いたします。紹介されていた本の中から、いくつか興味のあるものがありましたので、さっそく購入して読んでみたいとおもいます。

コメントの投稿

管理者にだけ表示を許可する

トラックバック

http://emasaka.blog65.fc2.com/tb.php/952-5eb429c1

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad