東北・福島へ 2012/03

3月3日・4日の両日、福島県のいわき市に沖縄三線の演奏に行きました。
東日本大震災で被害を受けられた場所へ沖縄民謡やポップスを聞いてもらいに行きました。今回も一人きりで活動をしてみる事にしました。

いわき市は昨年10月に久保田晃平教師に同行していった場所です。
その時はいわき市出身のたかえちゃんがコーディネートしてくれましたが、
今回は自分で考えて活動場所を探してみました。
トータルで4カ所での活動となりました。

3月3日　いわき市

3月３日は１カ所のみの活動としました。

まずはいわき市の泉町にある早稲田集会所という場所にて演奏しました。
この集会場は、いわき市で被災された方が居住する雇用促進住宅や、近隣住民の方が利用される場所です。13時から15時までのお茶会の間で、三線を演奏するという内容でした。先週は二胡の演奏会があったそうです。

いわき市は東北地方の中でも温暖な気候といわれますが、
風は少し強く、まだ肌寒く感じます、春が来るまでもう少しの時間が必要でしょうか。

今回も少し休憩を挟ましてもらいながら、１時間ほど演奏しました。
途中いわき社協の職員の方が飛び入りで島唄を唄ってくださり、
とてもいい雰囲気でした。私も楽しかったです。ありがとうございます。
住民の方から、珍しくリクエストをいただいたのですが、演奏できませんでした。
曲は「さとうきび畑」でした。また来てくださったら、次回は演奏できますように、
覚えておきたいと思います。
最後は皆さんと「ふるさと」を合唱して演奏は終わります。
上の写真は社協の方に許可を頂いて、一緒に撮らせてもらったものです。
いつも写真を撮り忘れてしまう事は非常に残念に思います。

歓談の時間にも混ぜてもらいます。こちらは「お茶っこ」っていうのでしょうか。聞くのを忘れました。
おやつに出たニョッキおいしかったです。いわきの人は気候からか、明るくで社交的な人が多いように感じました。
会がお開きになってから話をしました、
普段される活動の事、来週地震が発生してしまってから一年となる事、そして放射能の話...
放射能の話は積極的にしたくないのですが、どうしても気になってしまいます。
普段東京にいる自分としては無関係では無いですが、貴重な実際の話を聞かせてもらいました。
「みなさん、水道水は飲まない。」
「いわき市でも、山の麓は線量が高い場所が多い。」
「食べ物についても気をつかう」
短い時間でしたが、大変お世話になりました。また、これからもお伺いさせていただきたいです。
そう思いながら、集会場を後にします。明日は、いわき市に避難している、楢葉町民の方に歌を演奏しにいきます。現実を知るために、車で楢葉町に近づいてみる事にしました。

小名浜から海岸沿いに楢葉町を目指します。
アクアリーナにも行きたかったのですが、今回は時間が無いので諦めました。ぜひ次回。海岸沿いを車で進むと、被害の大きかった豊間地区が目につきます。
あたり一面がすべて流され大きな傷跡が残る事を改めて目の当たりにします。
もうすぐ震災から一年です。

それからは６号線をひたすら北上し、広野町役場を越えて、J-VILLAGEの手前に来た所で検問に当たったため、北上する事は断念しました。
J-VILLAGEの施設（J-VILLAGEスタジアム）には多くの仮設住宅が建設されていました。
多くの方がこの仮設に寝泊まりしながら、福島第一原発での作業に当たってくださるのだろうと
思い、複雑な気持ちでホテルに戻ります。世界的に名の知れ渡る事になってしまった、福島第一原発まで約20kmの距離でした。

ホテルにもどりましたが、一応旅ですので、先日再開しましたハワイアンリゾートに行ってみる事にしました。
到着した時間がかなり遅かったのですが、十分に施設を満喫しました。
館内に入ると、ちょうどフラガールのポリネシアンショーをやってました。
フラガールの踊りと笑顔に旅先での複雑な思いも癒されました。
これからも日本中の心を癒してほしいです。ありがとうございました。

その後は世界最大という露天風呂で体を暖めました。
湯船は暖かいのですが、強烈に冷たい風が顔に当り、変な間隔ではありましたが、心地よい時間でした。
部屋に戻るとぐっと疲れが出たのか、すぐに眠ってしまいました。

３月4日　いわき市

楢葉町の方が避難されている中央台高久の仮設住宅を目指します。
高久に到着した時、昨年10月に来た場所と同じ土地だという事に気づきます。
高久はいろんな地域から避難された方がおられる場所だと理解しました。
仮設住宅があまりにも多く、少し道に迷ってしまいました。
今日は楢葉町から、いわき市に避難された方が居住する仮設住宅3カ所に向かいます。
まず、高久第５仮設住宅です。
十数世帯とそれほど規模の大きくない仮設住宅ですが、多くの住民の方が集まってくださり、演奏しました。
80を越えたお父さんが踊っておどって会場を盛り上げてくれました。私よりも上手ですよ！。
沖縄に移住した方も多くいらっしゃるそうです。
「元気にされてるんですか？」と聞くと、「元気にしてるから、帰ってこないんよ」とおっしゃってました。私も沖縄行きたいなぁ。

次は高久第六仮設住宅です。
お昼休みを挟んでお邪魔させていただきました。
自治会長さんが面倒見の良い方で、この仮設住宅も団結力がありそうに感じます。
こちらでもお話をしながら歌を歌わせていただきます。
今日お会いする方は皆様、楢葉町から避難されている方達です。
皆さん、口を揃えて「2年は我慢する」とおっしゃります。
東電および国に除染をしっかりしてほしいというメッセージです。
本当に東電や国は、もうこれ以上、避難されている方をがっかりさせないでほしいです。もっと目に見えるように、有限実行、身を尽くしてほしいです。

最後に高久第八仮設住宅です。
いわき公園の中に立てられた大規模な仮設住宅です。
ペットを飼っておられる方が主にここに住まれておられます。
会場は大きな集会場でしたが、実は宣伝不足／準備不足から開始時間になっても、誰も集まりませんでした。
しょうがないので「安里屋ユンタ」を歌いながら、仮設の周りをぐるぐる歩きました。そうすると、２人のおばぁさんが声をかけてくれました。
おばぁさん達は、最初「散歩で疲れた」といいつつも、後で集会場にやってきてくれました。やさしいですね。
それで、おばぁさん二人と私の三人でしばらく会話をし、歌も少しだけ一緒に唄いました。
二人のおばぁさんのうち一人は、楢葉町の家に2度、一次帰宅したけど地震当時とまったく変わってないそうです。
本当にしつこいですが、除染ができるならキチンとやってほしいです。
高線量の森や木を除染するのは、至難の技だと住民の方は皆様認識されています。
家の片付けは私も手伝いに行きたいです。
最後の会場ではライブという形で演奏はできませんでしたが、こうして交流する事ができよかったと思いました。

まとめ

昨年7月に久保田さんに同行し、「冬は自分たちの力で訪れたい」と思い、昨年の12月から、2012年1月、2月、3月と毎月、東北を訪問し演奏をする事ができました。
なぜ冬に行きたいかと思ったかというと、冬は夏に比べ、ボランティアで訪問する人も少ないからとおもっていたからです。

確かな事はわかりませんが、いろいろな方の話を聞いて、夏場に比べこの冬被災地を訪れる人は少ないと聞いた意見が多かったので、訪問した事はよかったと思っています。これからたくさんの方が、また夏にかけて被災地を訪れる事でしょう。
来月はお休みするかも知れませんが、また続けて行きたいと思います。

東北・宮城へ 2012/02

18日、19日の両日、宮城県の南三陸町、女川町に沖縄三線の演奏に行きました。
東日本大震災で被害を受けられた場所へ沖縄民謡やポップスを聞いてもらいに行きました。
今回は一人きりで活動をしてみる事にしました。
これまで新幹線を活用していましたが、今回は高速バスを利用してみました。
冬の東北という事で運転する距離を減らしたいという事と、
移動費をやすく上げたいと考えたからでした。
17日の夜に夜行バスの中で、これまでの事を振り返り、
「本当に自分ひとりで行って迷惑かけないだろうか。」と
不安に思いましたが、いろいろな方が協力してくださって実現した事でも
あり、しっかりやり抜こうと改めて思いました。

2月18日 南三陸町

3カ所で活動をしました。

17日夜に東京新宿を出発したバスは朝6時半に石巻駅に到着しました。
レンタカー屋さんに行く予定時間は9時なので、
大変寒かったですが、する事もないので、街を歩いてみる事にしました。
昨年の5月に訪れた湊小学校までの距離を歩いてみる事にしました。
営業を再開しつつある店もありますが、まだ多くの店は被害を受けたままです。
昨年おとずれたライブハウス「La strada」さんのあったビルは解体されていました。
今はLa stradaさんは違う場所で営業されています。
傷ついた建物が少しずつ更地に変わりつつあります。

しばらく歩くと湊小学校に到着しました。
地震発生以来あった避難所はなくなり、入浴支援施設「希望の湯」も撤去されていました。
一階部分は震災で水没して壊れたままの状態です。
津波が校舎を襲った「3時48分」で時計の針は止まったままです。

さてライブです。
最初は小森仮設住宅で演奏させていただきました。
昨年12月に高橋さんと言った場所です。
またお世話になれて嬉しく思います。
肝心の演奏ですが、いつもそうですが最初のライブは間違いが多いです。
過去に２人で行った時は最初は息もあわず、だんだん回を重ねるごとに息があってくる感じでした。
今回は一人なので、大丈夫かと思いましたが、
初めての1人からか、違う事をしようとして、進行上でうまくいかない部分などがありました。
1人の人が「あんたの顔を見てるだけで癒されるのよ。また来てね。」と行ってくださり
ありがたいと思う反面、もっとクオリティを上げないともう行けないと思い、反省しました。
折角また訪問する機会をくださったのに、申し訳ない気持ちで一杯でした。
でも楽しい時間は作れたと思い、また機会があればと、小森仮設住宅を後にします。

次は戸倉神割キャンプ場仮設住宅です。
戸倉という場所は初めて訪問する場所でした。
戸倉はこれまで歌津と志津川を行き来するルートでは通らない場所でした。
仮設への道を進むにつれ、戸倉も非常に大きな被害をうけた場所だったという事を理解しました。
見てくれた人はすべて女性の方でした。
どの会場も年配の女性が多い。男性は仕事にでているといいます。
来月になると南三陸はわかめの収穫が始まるため、
女性の方も忙しくなるらしいです。
たくさん採れるといいですね。
今度は初回よりはスムーズに進行しました。
途中から85歳のおばあさんが踊りだして、会場を盛り上げてくださいました。
本当私よりも踊り上手ですね。
多くの方と握手をしてお別れします。

最後は戸倉中学校の仮設住宅です。
敷地の中に社会福祉協議会の事務所があって驚きました。
南三陸町がとても大きな地域という事が理解できます。
見てくださったのは30名ほどの方でした。
中にいた女の子供二人にからかわれながらも楽しく演奏をします。
1人で演奏する時は特にカチャーシーが難しいですね。
立派な演奏じゃないので、まずは立派に演奏する事ですが、
盛り上げるのって本当に難しいです。
経験がまだまだ全然足りないけれど、悩んで自分なりの成果を出せるようになりたいです。

宿は朝出発した石巻市内で予約しました。
北上川沿いを車で通りましたが、川が完全に凍結していてびっくりしました。
上品の郷という道の駅に、温泉施設があり体をあっためてから、石巻市に戻りました。

宿に戻り、久しぶりに行きたかった、レゲェ喫茶「Be-in」に行きましたが、
マスターはL.Aに遊びに行っているとの事、さすが自由人ですね。人生を楽しまれていますね。
素敵です。

2月19日 女川町

2カ所で活動をしました。

まずは、昨年12月に訪れた福祉仮設住宅を訪ねました。
二回目だと求められる事も増える。
人が前回と違う。
前回は福祉仮設住宅に同居する知的障害を持つ人達のグループもいて、
彼らが一緒に盛り上げてくれたのですが、今日はいませんでした。

演奏をしていて、楽しんでもらえているのか内心心配していましたが、
最後はカチャーシーで皆さん笑顔でした。ほっとしました。
演奏後は、社協の職員さんと話を少ししました。
地震発生時は深夜12時頃に暖房が切れ、それから五日間ほど暖房がなかったそうです。
みなさん毛布にくるまってひたすら耐えしのがれたそうです。
若い方はまだしも、年配の方がそのような状況で耐えられた姿を想像すると辛くなります。
今の寒さで暖房が無いと思うと本当にキツイです。

女川は市内中心部はほとんどの建物が流されてしまいました。
車で街を通ると、少し高台にある、女川高校の近くまでが家が流されてしまっていて驚きます。
演奏会場の建物である旧町立病院の駐車場が標高20メートルらしいですが、
一階部分が浸水して多くの方が流されてしまいました。
「この更地に建物が経って、去年のにぎやかな場所になるまでは、
10年かかるかもしれませんね。」
そう言って、落胆する職員の方にかけるべき言葉は見つかりませんでした。
もうすぐ地震発生から一年を迎えますが、復興はまだまだまだ先の話です。

次のライブまで時間があったので、少し街を周りました。
ドライブウェイのコバルトラインから、太平洋を見下ろします。
それから、女川名物、穴子丼を「ニューこのり」さんで食べました。

「ニューこのり」さんはお店が流されましたが、仮設の店舗で営業を再開されています。
食べられるか分からなかったので、食べる事ができて嬉しいです。
たくさんの方でお店はにぎわっていました。

そして福祉仮設住宅。
八十歳以上の方が多いようですが、正確な年齢は分かりませんでした。
みなさん今は車いすで生活されているようでしたが、
たくさんの方が集まってくださいました。
言葉を発する事も辛そうな方もおられ、
歌が伝わるか心配でしたが、しっかり伝わりました。
最後は多数の方が私の下手な説明でもカチャーシーに応じてくださいました、
皆さん楽しそうだった。手伝ってくださった看護師さんのおかげですね。
ありがとうございました。
途中、難しそうな顔をしてたおばぁちゃんが、
「女川がこんなになってしまってずっと悲しかったけど、
今日は楽しかった。またいろんな場所に行って聞かせてあげなさい。」
と言ってくれました。
こらえましたが涙がでる位に嬉しかったです。来てよかったと思いました。
また会う約束をして東京に戻る仕度をしました。

まとめ

1人で全てやってみて、最低限やりたい事「楽しい時間を作る」事はできたと思います。
前回岩手に行った時に書いた「寄り添う」事については、できたか分かりません。
私は毎日現地でともに生活している訳ではないですし、とても寄り添っているとは言えませんが、
少しでも、そのような気持ちで皆さんと接したいと思います。

そして演奏については、まだまだクオリティが高くないです。
これまで二人だから、ごまかしが効いた部分があれども
それも一人だと期待できません。
ですが、暫くはもうすこし1人で悩みながら、前に進めたいと思いました。
二日間で、合計5カ所の仮設ライブを一人でこなす事ができるか、
のどが持つかを本当に心配しましたが、無事に唄いきる事ができたのは本当によかったです。
のどが少し鍛えられたのかもしれませんが、たまたま、もってくれただけの事かも知れません。
経験を積んで行かないとよく分からない事かもしれません。

今日から新たな一週間です。
新たな気持ちで頑張りましょう。

まごころネットさんのホームページに活動内容が掲載されました。

先月28日に大槌町で活動した内容が、まごころネットさんのホームページに紹介されていました。

http://tonomagokoro.net/archives/12954

このように紹介していただく事が、我々の励みになると同様に、私よりもっと素敵な演奏をされる方が、この東北の地に向かってくださればと思います。

東北・岩手へ 2012/01

気がつけば、2年近く更新を放置していました。
小金井市住民という事でつけたタイトルも住所が変わってしまったため、
いろいろ趣旨は書き始め当初と異なりますが、久しぶりに記事を書いてみたいと思います。

はじめに

28日、29日の両日、岩手県の各地に沖縄三線の演奏に行きました。
東日本大震災で被害を受けられた場所へ沖縄民謡やポップスを聞いてもらいに行きました。
当初は私の兄弟子である、八重山古典民謡保存会の
久保田晃平教師に付き添う形で、昨年の7月／10月に被災地へ行きましたが、
どうしても自分の力で成し遂げたいという思いで、
昨年12月から、友人を連れて、ごく少人数で行く行為を開始しました。

メンバー

・私
・HAYA（八重山民謡を一緒に学ぶ同門の仲間）
・たかはしさん（昨年12月に一緒に宮城に行った仲間）
の3人でした。
最初は私とHAYAの2人で開始し、
29日の昼から、たかはしさんが加わりました。

グループ名

グループ名が何か必要との事で、HAYAがつけてくれた名前は
「あがいてぃーら」（※昇る太陽の意）という素敵な名前をつけてくれました。

1月28日 宮古・大槌

宮古市で2カ所、大槌町で1カ所活動をしました。
岩手県盛岡まで新幹線で北上し、レンタカーを借りて
宮古市に向かいました。
開始まで時間があったので、


宮古市の鍬ヶ崎にある、「魚正」さんでお寿司のランチを食べました。
「魚正」さんも大きな被害を受けたが、何とかおいしいお寿司を提供したいとの強い思いで、
お店の営業を再開されたそうです。
まぐろといかがおすすめとの事でしたが、とても新鮮でおいしい魚を堪能しました。
宮古に行かれたら、是非海の幸をご堪能下さい。
http://r.tabelog.com/iwate/A0304/A030401/3000045/

そしてライブです。
宮古市の一カ所目は、鍬ヶ崎という地域でした。
大変大きな被害を受けた地域です。
演奏は初回の緊張からか、特にいろいろ間違えた（※本当に反省）
のですが、へこまず楽しく演奏ができました。
少しだけ度胸がついてきたのでしょうか。
私の母親くらいの年齢の女性がお客さんに多いです。
宮古市は、沖縄県の宮古島の多良間村と姉妹都市の関係だそうです。
演奏後、お茶っこ（岩手では近所の人が集まるティータイムの時間をそう呼ぶそうです。）
に少し混ぜてもらったのち、会場を後にします。

宮古市の二カ所目は、崎山という地区に行きました。
こちらでも同様の演奏を行いました。
鍬ヶ崎よりも少し高齢の方が多かったです。
会場でこたつの中で、ちゃんちゃんこを着ながら、
待って下さっていて、テレビで見たような光景です。
最終的には、カチャーシーで皆様の笑顔が見れたのですが、
なかなか雰囲気を盛り上げる事が難しかったです。
もっと皆様に寄り添う気持ちが足りなかったのかもしれません。

次は岩手県大槌町のあるサポートセンターに移動し、演奏をしました。

今回サポートしてくださったのは、遠野まごころネットの「大槌おちゃっこ隊」の
皆様です。遠野まごころネットは震災後、様々な活動で被災した地域を支援する
ボランティアネットワークです。
私も昨年5月にお世話になりましたが、またこのように関わりを持てて本当に有難く思います。

今回はまごころネットさんの企画協力のもと、
夜にお酒を少し呑んでいただきながら演奏するという事になりました。
われわれもオリオンビールをわずかばかりですが、持参しました。
少しだけでも、民謡酒場的な雰囲気を、つたない演奏ながら感じてもらえたらと思い、
頑張りました。

ライブ後、大槌おちゃっこ隊の方々と打ち上げです。
いろいろ話を聞きました。
・まごころネットのこと
・いろいろな方が被災地にやってくる話
・仮設の話（集会場の無い小さな仮設から大きな仮設まで数多くの仮設が存在する）

ミュージシャンもたくさん来るそうですが、
とにかく、「俺の歌を聞いてくれ」且つ、クォリティの低い人が少なからずおられるようです。私たちも紙一重かと思っています。
被災地に歌いに行く人は、私も含めてですが、相手がどの様な気持ちで
迎えてくれるのかを、もっと感じなければいけないと思います。

おちゃっこ隊の人と話をしていて、
キチンとしたクオリティで演奏したいと同時に、
もっと皆様の心に寄り添いたくて、ここに来たんだなぁと感じました。
おちゃっこ隊のみなさまと会えてよかった。原点を思いだしました。
春になれば、集会所のない小さな仮設に一人で行こうと決めました。
また可能なら、一緒に活動させてもらいたいです。

まごころネットは5月に震災後初めて行った場所ですが、
どこのボランティアセンターも受け入れを拒否せざるを得ない状況の仲で、
我々を受け入れてくれた場所です。
あの時、遠野で多くの方が流された涙は忘れる事がないだろうと思います。

その後、宿のある釜石市内に戻り、HAYAと2次会です。
市内中心部なのに、津波の被害はいまだ深刻で、
震災から、もうすぐ1年ですが、まだまだ状況はよくなりそうにありません。

1月29日 釜石・陸前高田

朝から桜木町のサポートセンターに向かいます。
こちらも大きな会場です。私たちにはもったいな過ぎる会場です。

この日は地区の新年会を行うとの事で、「マグロの解体ショー」など
興味深いイベントの中に我々の演奏も加えていただきました。
この上ない光栄な話でした。

ほとんどMCのHAYAが頑張ってくれましたが、
私も少しだけ伝えたい事を話しました。
昨年5月に初めてボランティアに来て、
サンマを拾ったり、瓦礫を拾ったりしてました。
音楽を演奏しに来たけど、聞いて欲しいのではなくて、
皆さんと一緒に唄いたい事。
音楽の演奏も、あくまでもボランティアとして取り組んでいる事
を話ました。
そして少し気持ちが楽になりました。
自分の気持ちが通じたのか、空気感が変わり、皆さんと仲良くなれた気がしました。
聞いてくださる方達に感謝をしながら、残りの時間歌を歌いました。

演奏が終わってから、マグロの解体ショーです、
滅多に見れない素晴らしい催し、ぜひ見たいけど、泣く泣く会場を後にします。
ですが、特別に握ってくださったマグロの握りすしを移動中の車内でほおばりました。
ほんとにおいしくて、ずっとよかったなぁと言ってました。

13時に陸前高田に到着しました。
三日市という場所に来ました。
ここから高橋さんが合流して、仮設に向かいます。
こちらの仮設の会長さんは、元々近くの高校の校長先生と聞きます。
ここは車座になって我々を迎えてくださいました。
今まで4箇所で活動しましたが、ここは団結力が抜群でした。
みなさんが元々知り合いなので、コミュニティーが出来上がっていました。
カチャーシーは何も言っていないのに、民謡酒場のように、
輪になってぐるぐる回られていました。
楽しかった！

そして最後は三日市の近くの仮設で活動です。
ここは2年前に西表島で知り合った友達と、友達のお母さんが探してくれた場所でした。
友達は陸前高田出身で、お母さんは陸前高田で生活をされています。
素敵なチラシまで作ってくださいました。本当にお世話になりました。
すこし開始時間に遅れてしまい、
お客さんを待たせてしまいます。本当に申し訳ありません。
最初はみなさんの、どこの馬の骨か分からない我々を見つめておられました。
ですが、ライブが始まり時間が経つと、仲良くなるのに時間はかかりませんでした。
最後はみなさんと一緒に「北国の春」を合唱して終わりです。

ライブが終わり仮設でごちそうを呼ばれます。
ほんとにこんなに甘えていいのかなぁと思いつつも、
住民の方のやさしさに触れて本当に胸一杯の気持ちで東京への帰路につきました。

まとめ

極寒の東北を身をもって経験しましたが、
皆様の温かさをたくさん頂いたおかげか、
寒さはあまり感じませんでした。

MCはHAYAが担当。
いろいろ大変でしたが、
民謡や沖縄ポップスの説明を分かりやすく聞いている人に
伝えてくれたと思います。
ありがとう、HAYA！。お世話になりました。
次は自分で頑張ってみます。

たかはしさんは、元々生まれのルーツが
陸前高田にあり、多忙の中来てくれました。
陸前高田の人達と我々をよりつないでくれたと思います。
ありがとう！。また機会があれば演奏に出かけましょう。

次回は一人で宮城に行ってみようと思います。
「ボランティアは自己完結」とは理解しながら、
実践できていないので、なんとか自分で解決できるようにしたいと思っています。
次はもっとミスを減らすように、そしてもっと「寄り添える」ようにと思います。

DeNA Technology Seminar #1に参加しました。

DeNA Technology Seminar #1 Inside OpenSocial Container

3月16日に、株式会社ディー・エヌ・エーさんで開催された「DeNA Technology Seminar #1」 に参加してきました。

先日PHP勉強会に参加した時に、mixiのwebooさんが、今回のセミナー開催を告知されてて、とても楽しみにしていました。

セミナーを聞いた感想として、普段利用している2大ソーシャルアプリの裏側で、Perlがこんな風に活躍しているのだなと、感じる事のできたセミナーでした。

発表者の方々、関係者の方々、ありがとうございました。とても楽しく勉強になりました。次回も開催されれば是非参加したいです。

理解できていない内容も多く、帰ってUstreamを聞きながら、もう1週間経ちますが、メモを整理しました。
内容として誤解している部分がありましたら、ご指摘いただければ修正します。

◎発表 その１

Inside MBGA Open Platform API architecture

発表者：zigorouさん

MBGA Open Platformの実装を担当しておられるzigorouさんが、Open Platform API全般についての説明をしてくださいました。

概要

＊WAFについて
WAFはCatalystを採用（但し、dispatcherとしての役割に限定して使用）。
Catalystについては、moose版を使用。特にCatalystらしい機能は使っておらず、Pluginも、ConfigLoader、Log::Dispatch、Unicodeだけを使用。

以前、CatalystについてのプロファイリングをDevel::NYTProfを使って実施した際、高コストの処理として、Class::MOPがたくさんピックアップされた。
結論的に、Catalyst Moose版を使えるのは、小中規模のサービスまで。
大規模開発の場合は、富豪的にコードを書くと後が大変。
現時点で運用中のCatalyst Moose版で困っているわけではないが、いずれ、Plack + 薄いWAFに差し替える予定。

＊Webサーバーについて
Webサーバーはlighttpd＋fastcgiで構築。
fastcgi絡みであった過去のトラブル
・loadが高い時に勝手にbackendへの接続を絞ってしまった。
・fastcgiからのresponse eventを受け取ったのに、responseを読めない謎のバグがあった。
lighttpdは、stableとは言いきれない！。

fastcgiはdeamon toolsで運用していて、deamon toolsのmultilogは使っていない。

＊MYSQLについて
DBへのアクセスについては、DBIx::DBHResolver、DBI等を使用。またSQL文については、SQL::Abstractを使ったり、生のSQL文を書いたりする。
MYSQLのストレージエンジンは、基本InnoDBで、擬似sequence用のテーブルや検索系テーブルのみMyISAMを使用。
DBはMaster×1、Slave×3、Backup×1で一つのクラスタとして構成。user情報など参照頻度の高いクラスターについては、slaveが数10台のような構成もある。
歴史的な経緯もあってラックが複数拠点にあったりして、replicationが拠点をまたぐ事もあるが、最近は専用線を増強したので、それほど気になる事ではない。

memcached更新用trigger専用slaveというのがある。
特定slaveのみtriggerを仕込み、更新のあったデータのみを別テーブルに抽出。
抽出したデータを読み込みmemcachedに突っ込んだりする。
キャッシュのデータを読み込んだ際にレプリケーションの遅延などはほとんど発生しない。

＊開発について
※svnでレポジトリ管理してるが、いずれgitに移行予定。

開発手順は以下のとおり。
(1)ローカルでテスト（Test::mysqld、Test::TCP）
(2)stageにdeployして動作確認。
(3)sandboxにdeployする。
(4)serviceにdeployする。

＊Deployについて
Archerを採用。
Archerの運用に関しては、基本そのまま運用しているが、サーバーの構成がたびたび変わるので、以前Yamlにホスト名を書いていた部分をプラグイン化したりしてる。

Deployの仕方は、rsyncして、lighttpdを落として、svc -t /service/myappしてlighttpdをあげる。
そのうちPlack with PSSPSS化したい。

＊CPANの管理について
CPANモジュールについては、rpmとyum repostoryで管理してる。CPAN::Packagerを利用。
yum reposの更新および管理については、自社のお手製ツールを利用。
開発環境も本番と同じ、yum reposでyum groupupdateをしていて、開発環境もサーバー数が多いので、これらもArcherを活用。

＊監視系について
・監視ツールはnagiosや、mysql系の監視には自社作成のツールで能動的にチェック。
・syslog-ngでログを集めてログの監視を行っている。当初はTCPでログ転送する予定だったが、現状UDPによるログ転送を実施。

アーキテクチャについて

＊提供API
a) OpenSocial RESTful APIs　=> People、Appdata、Activity、Messageを提供。
b) mbga Game API（独自API）=> Payment、TextData、Ads、BlackList、NGWordなどを提供

※上記APIのうち、以下はいくつかを詳しく説明してくださいました。
＊People APIについて（OpenSocial RESTful APIs > Perple）
・自分自身の情報を取得する場合（GET /people/@me/@self）
・viewer(閲覧者)自身のプロフィールを取得するパラメータ
・key-valueで簡単に取得できるので、memcachedでのやりとりが可能。

閲覧者の友達情報を取得する場合（GET /people/@me/@friends）
・アプリをインストールしている、していないを検索条件に指定。
( hasAppパラメータを「true」か「false」で定義 )
・最大1000件取得できますが、無茶はしないでくださいね。

友達情報取得する場合、複数のテーブルを参照している。

友達情報取得する際に発生した問題
max_allowed_packet問題
モバゲーの友達数は無制限なので、max_allowed_packetの値のdafault値1MBを越えてしまう場合がある。
対応として、
・クエリが単純に分割可能ならば分割してアプリでマージ。
・分割できない場合は、CREATE TEMPORARY TABLEコマンドで、一時テーブルを作成する。

＊Message APIについて（OpenSocial RESTful APIs > Message）
Message APIとは、アプリがユーザーに、もしくはユーザーがユーザーに対して通知を行うAPIで、タイトル自身はアプリケーションごとに決める。
タイトル例) hidekさんから応援バトル依頼

Message/Activityを叩きまくるアプリに対する対策。
・特定条件を満たした場合の通知は一分間に一回に制限（cacheに格納）。
・アプリからのメッセージ送信については4時間に一通に制限（DBに格納）。

ユーザーにMessageが配信されるまで
Message API or 内部APIでQ4Mにinsert（Open Platform以外でも怪盗ロワイヤルなどでこの方法を実施）
・Activity/Messageで2000万/day以上の通知があるため、masterの書き込みは制限したい。

＊MYSQL Partitioning
Massage/Activityで採用し、日単位で分割している。
Rangeが効くQueryだと高速。
保持期間をすぎたら　DROP PARTITIONを実行する。
難点は分割に使ったカラムをuniqueインデックスに含めなければならないところ。

＊Profiling
実行時間が敷居値を超えたものはログに書き出しを実施。
API、アプリごとにデータを収集し、最適化を実施。
DBIx::ProfileManagerで0.1%でSQLのProfile結果をログに書き出しを行う。

参考ページ
http://engineer.dena.jp/2010/03/dbixprofilemanager-sql-profiling.html

まとめ

好きな技術をチョイスしている。
CPANモジュールもありがたく利用させていただいている。

その上で、気に入らなければ、自らコードを書いたり、
テストをきちんと書いた上で変更する。

トラフィックが多いと想定外な事が多く、普段から
ケチ臭くプログラムを書く事が重要！。

---

◎発表 その２

mixiアプリプラットフォームについて

発表者：webooさん

次は、mixiのwebooさんが
mixiアプリプラットフォームについての説明をしてくださいました。

●mixiアプリモバイルについて
現在、mixi Platformというオープン化戦略を展開。
mixi.jpの中でアプリを作れるもの => mixiアプリ。
外部からmixiのソーシャルグラフにアクセスして、アプリを作る=> mixi Connect。

pcとモバイルでアプリを提供できるのは、mixiだけ。

pc版とモバイル版でいずれも、mixiアプリを実装する為にガジェットxmlが必要だが、ガジェットXMLの中で並べて併記することも可能。
pcから実行すれば、PC用のContent-Typeが読み込まれ、モバイルから起動すれば、モバイル用のContent-typeが読み込まれる。

●mixiアプリモバイルの構成
mixiがアプリモバイルのプラットフォーム内部について
Aprication Proxy(HTMLファイル)と、
Media Proxy(画像／flashファイル)が存在する。

＊Aprication Proxyについて
・HTMLファイルを処理する。
・User Flow APIタグの展開。
・広告タグの展開。
・mixiヘッダー/フッターを追加する。
・UID/Cookieヘッダーを削除する。

＊Media Proxyについて
・画像やFlashを処理する。
・response bodyのパースはしない。
・UID/Cookieヘッダーを削除する。
・ファイルサイズのチェック

●サーバー構成
サーバー構成は、mod_proxy + mod_perl + squid。
アプリケーション情報はmemcachedに格納。
DBアクセスはほとんど無い。
フレームワークは使用しないで、スクラッチから実装している。

●負荷についてのお話
モバイル版のリリースが、仕様公開から正式オープンまで、6ヶ月。
PC版リリース時、多数のアプリが負荷によってダウンしたので、モバイル版では、同様の事がおこらないようにしたかった。

＊正式リリース前に行った負荷対策と結果
(1)5秒以内にレスポンスを返さなければタイムアウトにする。
・一定回数タイムアウトされると、新規ユーザーの登録が不可に。
・更にアプリ一覧からも表示されなくなる。
・解除するには、mixiに対して報告をする必要がありとした。
(2)リリース前に負荷テストの実施状況をヒアリングした。
・負荷内容、負荷試験実施環境、負荷試験においての想定許容内容、実施日、結果を各SAPさんに問い合わせ。
・結果すべてのSAPさんから「問題なし」の回答　
・実際にリリースすると、ほぼすべてのSAPサーバーがjoin停止状態になってしまった。
・負荷に耐えた一部アプリだけが残った（一部のアプリは5日で100万人ユーザー達成！）

＊リリース後の緊急対策
・タイムアウト制限を10秒に緩和。
・画像ファイルのキャッシュを開始(squid上にて)。
・パフォーマンス向上のお願いを各SAPサーバーさんに行った。
・画像やFrashについての署名(OAuth Signiture)については、オプション化した。
・Devel::NYTProfを使ってプロファイリングも実施。

Opoen Social for Mobileは、SAPさんとmixi Platform双方が連携しないとうまく動作しない。

2009年10月〜11月にかけて
SAPに対して開発／運用に関するコンサルティングをした結果、
以下の事がわかった。
a). 開発言語は、PHPとJavaが多い
b). DBはMySQLが多い
c). memcachedを使っていない。
d). 非同期処理を、mixiアプリ自体にforkで記述していた。
e). 環境がWebサーバー1台+DBサーバー1台というSAPさんもおられた。
上記の調査結果を踏まえ、環境向上に取り組んだ結果、負荷もだいぶん軽減された。

●Plack + AnyEventモデルへの移行
mixi Platform自体でも、構成の見直しを行い、
3月上旬に、Plack + AnyEventモデルへの移行を実施した。

従来のmod_perl版では、
一部のレスポンスの悪いアプリがあるとPlatform全体が引きずられてしまっていた。

Plack + AnyEvent版では
携帯からリクエストされるとサーバー上のPlack::Server::AnyEvent::Preforkが処理をする。
SAPサーバーとのやりとりはCoro::AnyEventで行い、SAPサーバーへのリクエストをnon-Blocking化する事で、一部アプリが遅くても全体に影響を与えないようにした。
DBへのアクセスは内部API呼ばれたmod_perlが担当する。

いろいろ試した結果、Plackとmod_perlを1台のサーバに同居させた。
Plack+AnyEventの負荷は無視できる。
PlackとInternal API間の通信は、HTTPで行う。
65台のアプリ用サーバが可動中

●Tokyo TyrantとQ4Mについて
＊Tokyo Tyrant
・「最近使ったアプリ」へのデータ格納に利用。
・書き込みが多い処理に最適。
・マスタ1台+スタンバイ1台で構成。

＊Q4M
・ライフサイクルイベントに利用。
・OpenSocial v0.9仕様。
・ユーザーのアプリ登録/削除をSAPサーバーに対して、POST/GETで通知する処理に使用。

●コンテンツ配信サーバー
・三月上旬に公開しました。
・静的ファイルを代理配信、CDN的に使える。
・WebDAVでアップロード。
・無料で利用可能。

●まとめ
ヒットすると、数千万〜数億PV／日のアクセスがくるため、対応するインフラの技術力が必要で、１００台規模のサーバーを用意しているSAPもあるくらい大変な労力が必要だが、エンジニアにとって、大きなチャンスでもある。

●今後の予定
・Activity（重要なものが目立つように)。
・PCからアクセス可能な動作テスト環境を準備中。
・OpenSocoal0.9対応を夏までに完了予定。
・モバイルアプリ仕様の統一。

---

◎発表 その３

Inside MBGA Open Platform - GADGET SERVER -

発表者：hide-kさん

Denaの木村さんが、
モバゲーOpen Platformのガジェットサーバ周りについて
お話をしてくださいました。

●MBGA Open Platform概要
・モバゲータウンとプラットフォームとして公開。
・OpenSocial 0.9準拠。

●Gadgetサーバーの持つ役割
・携帯とSAPサーバーのリクエスト/レスポンスを中継する役割。
・ユーザーの認証機能を持つ。
・OAuth signitureを携帯リクエストから生成する。
・リクエストごとにAccess Tokenの発行をする
・レスポンスコンテンツに対しての整形を行う。

●Gadgetサーバーを「Hermit」と命名
・Perl/PSGI/Plackを採用。
・Plaggableな構成を意識した。

●PSGI/Plackを採用した理由
(1)必要なものは、Web Applicationではない
・Dispatcherが不要なので、Catalystよりも薄いものでよかった。
(2)すでに実装されたものがある。 => Plack::Handler::*や、Starman

●PSGI/Plack
サーバー環境は、lighttpd + Plack::Server::FCGI。

アクセス数は1サーバーあたり、300プロセス。
一日では、1サーバあたり、550万〜600万リクエストをさばいている。
ピーク時のリクエスト数は、1サーバの1時間あたり、36万〜38万リクエストをさばいている。
(うち、最大5秒かかるリクエストもあるので、もっと処理は可能。)
あと2倍のリクエストはこなせそう。

●Pluggable
Pluggerライクなプラグイン機構
=> Class::Triggerを利用
Pluggableな構成を採用した理由は、仕様変更が猛烈に多かった。
結果、拡張がしやすく、メンテナンスが楽で、テストもしやすくなった。
（Pluggableな構成をとる事で、多少のパフォーマンス劣化はあるかもしれないが、メリットのほうが大きかった。）

Plugin::Request, Plugin::Responseでリクエスト/レスポンスを加工。
機能ごとにプラグイン化すれば、機能追加やバグの検証なども修正すべき箇所が限定されて作業がしやすくなった。

●その他利用するCPANモジュール
Text::MicroTemplate => footer等
HTTP::MobileAgent
HTML::SticyQuery::DocomoUID
OAuth::Lite
HTML::filter::Callbacks
DBIx::DBHResolver
Log::Dispatch
Test::TCP

●その他
＊Sandboxについて
・2009年11月に本番に先駆けて、Sandbox(Developper向け開発環境）を公開。
・開発環境=擬似モバゲータウン。
・実機での登録が必要。
・PCでのアクセスも可能。
・近いうちに全開放予定。

＊CDN => 静的ファイルはデフォルトですべてCDNを通す（お代はDena持ち）

●実際にプロジェクトを通じてきつかった事
＊スケジュール
・2009年8月1日にプロジェクト開始で、2009年11月24日リリースという予定で、全然期間がなかった。
・実際にコードを書き始めてのも2009年11月の初旬からだったが、短期間でリリースにこぎつけたのは、Plackのおかげだった。

＊パフォーマンス
メモリーよりもCPU使用率が問題となり、プロファイルを実施。
・Devel::NYTProfや、Unix::Getusageを使用。
※Hyper-Threadingの設定がoffになっていたが、設定を変えることでcpuのパワーが2倍になった。

●よくわからない現象
＊lighttpdがやたらエラーを吐く現象。lighttpd 1.4.23にバージョンアップしたら解消した。

●現在抱える問題
＊サーバー環境
・FCGI => よくわからない部分が多い。Reverse Proxy(Starman)に変更する予定。
・sslを今後使う可能性を考え、lighttpdを採用しているが、sslを今後も使わないので、フロントエンドいらないという結論。

＊ネットワーク問題 => タイムアウト(5秒)設定があり、頻発すると自動メンテナンスモードになってしまう(アプリが使えなくなってしまう)。タイムアウト時間を伸ばすくらいしか対応策がない。
※Amazon EC2が盛んに使われているけど、通信先が海外なのでタイムロスがどうしてもかかってしまう。早く日本初のクラウドサービスがでてくるといいね！。

●将来的に臨みたい事
＊スマートフォンや外部アプリケーションへの対応
・認証、認可をどうするかが今の検討課題。
・XAuthはクライアンとを信用しなければならない、どうするか？

＊OpenSocial 1.0にこれから対応していきたい。

＊Template化
・OpenSocial Templateを導入して、ユーザーがApiにアクセスしなくてもよくしたい。
・現状キャリア判定などは、アプリサーバーが各自に行っているが、出来ればプラットフォーム内部で解決したい。

●結論
・Plackは実務で使えるレベル
・実際に動かさないとわからない問題もある。
・今のアーキテクチャから脱却したい！=> よりパートナーやユーザーが使いやすいものを使っていきたい。

第50回 PHP勉強会に参加しました。

今週の月曜日、第50回のPHP勉強会に参加してきました。
http://events.php.gr.jp/events/show/90

これまでPHPを触る機会が少なかったのですが、良い機会だと思い、参加してみました。
それから、ブログに書く事も勉強会の一環とのご指摘があったので、エントリーしました。

内容的には、オープンソーシャルがテーマという事で、それほどPHPの理解が浅くても理解して聞く事ができました。

当日は3人のスピーカーの方が発表をされました。

1. mixiアプリについて（Weboo!さん）

mixiアプリがスタートして数ヶ月が過ぎ、ミクシーアプリの概要から、運用上の大変なポイントを教えていただきました。
mixiはソーシャルグラフを用いたアプリであって、友人とつながってゲームを進めたりすることに意義があるとの事。
PCでは、OpenSocial Javascript APIの理解が必要。モバイルでは、OpenSocial Restful Protocol。
mixiでは、Open Social用のAPIとミクシー独自のAPIがあるそうです。
大事なのは、もしヒットした時の対策。ヒットすると、数千万〜数億PV/日のアクセスがくるかもらしいです。ユーザーがリクエストしてから、10秒以内にレスポンスを返す必要があります。OpenSocial APIを使う部分では、下手をすると何度もコンテナと何度もリクエストを繰り返す事もあるので、外部サーバーにmemcachedを入れたりする必要があるとの話でした。

2. PHPでWEB開発を行うようにしてオープンソーシャルアプリを作る（KuniTsujiさん）

普段CodelgniterというPHPフレームワークで開発をされるらしいですが、Flashを使わずに、Mixiアプリが作れないかという事で、取り組みをされた事のお話でした。
モバイル版とPC版で比較した場合、モバイル版のほうが、取り組みやすいとの事で、今回はモバイル版作成でのポイントが中心でした。
Mixiアプリを作る際に、GadgetXMLが必要ですが、GadgetXMLの内容をPHPで自動生成させることで処理してるそうです。

まず必要な処理として、以下のものがあるとの事。
1.gadgets.util.registerOnLoadHandler(init)でVIEWER,OWNER,アプリ情報を取得する。
2. gedgets.io.makeRequestを使ってサーバに接続し、リソースを取得する。
3. ページ移動するため、gadgets.views.requestNavigateTo(supportedViews[view].params);が必要
他に取り組んだ事として、OAuthの処理を意識させないライブラリを作った事。
大事なのは、やはりサーバのインフラ周りや、膨大なリクエストをどう捌くか、DBの負荷をどうするかよく考える事が重要だろうとの話でした。

3.運用した気になるモバイルオープンソーシャル (個々一番)
昨年から開発を行い、リリースされたmixiアプリモバイル版「まちつく!」についてのお話でした。大変な苦労があって、ヒット商品としての現在があるとの事でした。
リリース後に遥に予想を超えるユーザーが来て（リリースしてから、毎日10万人会員が増えるペース…） 、様々な実施された対策をお聞きしました。
まず、画像生成用の外部サーバーのロードアベレージが一番ネックだったので、画像生成をキュー処理に書き換えたり、ボトルネック処理を全部つぶしたりして当時対応されたそうです。あとは、memcachedの適用範囲を大幅にしたり、DBマスターを分割したり（ORMを使ったり）することが負荷対策に有効だったようです。
いろいろ苦労をして負荷対策をしたけど、最大の負荷対策はサーバーのランクを上げる事で解消できたそうです。

すべての発表者の方を通じて印象的だったのは、インフラの整備をしっかりして置かないと大変になるという事でした。
オープンソーシャルアプリの開発は、いつヒットするかもしれないし、最初から大規模なインフラの準備は必要ないかもしれないけれど、もしヒットしたら、それからは長いアプリと負荷対策と改修の付き合いの始まりとなる。何か他にまた勉強したことがあればエントリーしてゆこうと思います。

運営者の皆様、スピーカーの方々、そして会場をご提供くださったコンテンツワン様、貴重な機会をありがとうございました。今後とも宜しくお願い致します。

utf8_heavy.pl について

社内で配信システムのパフォーマンス検証をDevel::NYTProfを利用して先日行ってましたが、
結果、多くの配信リクエストにutf8_heavy.plというツールがロードされていて、動作コストを食う一因となっていた事を確認していました。

明示的にロードしていないはずのutf8_heavy.plが、どのような状況でロードされるのか、ひととおりの理解ができたと思ったので、自分のメモとして残しておこうと思いました。

自分の理解では、
utf8フラグが立った文字列に対してある処理を行う際、
Unicodeデータを内部的に処理するためのデータ構造の
swatchとswashを生成するために、
utf8_heavy.plで定義されたSWASHGETメソッドが呼び出されていると理解しました。

参考ページ
http://homepage1.nifty.com/nomenclator/perl/swash.htm

おこりうるケースと例を想定
(1)文字プロパティ (\p{ }, \P{ })を用いた正規表現を利用した場合

use strict;
use warnings;
use utf8;

my $string = '超ハラ減ったし';

my @list = (
    $string =~ m/
        (
           \p{N}+ | \p{Han}+ | \p{Hiragana} | \p{Katakana}
        ) /gxmso
);
print join ( ',', @list );

(2)受け取った文字列をdecodeしてutf8フラグを立てた後に、
urlエンコードをしたり、文字のマッチング（\wや\Wや\D等）や
文字の加工 (tr///, y///, uc, lc, ucfirst, lcfirst, \U, \L, \u, \l) 
を行った場合

use Encode;
use strict;

my $text = decode('utf8', '超ハラ減ったし');
$text =~ s/([^\w ])/'%'.unpack('H2', $1)/eg;
$text =~ tr/ /+/;
print $text;

いずれの例でも-dオプションをつけて、perlを実効したところ、utf8_heavy.plがロードされている事を確認しました。

対処法としてこれまで、urlエンコードに使っていたunpack関数をURI::Escapeにしてみたりして、
正規表現も別の方法に変えてみたりして対応しました。

配信処理のパフォーマンスを少しでも上げたい場合、
ロードされているutf8_heavy.plに注目するのも一つの方法だと感じました。

内容的に間違いがありましたら、ご指摘いただければ、ありがたく思います。
宜しくお願い致します。