僕のラズパイが超簡単に AWS に繋がった話

ラズパイを AWS に繋いでみたい

今週はあまり大した内容を書けない。

前回、ラズパイを買ってモニタに繋いだ。

tercel-tech.hatenablog.com

次にやってみたかったことが、AWS 連携である。

もう少し具体的に言うと、データ収集基盤(っぽいもの)を AWS で構築して、ラズパイからデータを吸い出して遊んだり、あるいはスマホからラズパイを遠隔操作したりということをやってみたかった。

なんとなくこれまでの知識では、AWSAPI Gateway と Lambda をうまく活用できまいかと思っていたのだが、実は AWS は IoT 向けにナイスな仕組みを用意してくれていた。

AWS IoT のしくみ

AWS の IoT コンソールにログインすると、「AWS IoT のしくみ」というチュートリアルが見られる。

これは、5分くらいで AWS IoT Core の全体感をかんできて面白い。 チュートリアルというよりツアーに近いかも知れない。

f:id:tercel_s:20210410210557p:plain

基本的には、MQTT (Message Queuing Telemetry Transport) というプロトコルを利用した Pubパブ/Subサブ型のアーキテクチャが採用されている。

たとえ、物理デバイスがオフラインであっても、仮想的なシャドーデバイスによって、デバイスの情報にアクセスできる仕組みが整っているという。

クイック接続を試す

初めの一歩として、「AWS IoT クイック接続を試す - AWS IoT Core」という公式チュートリアルを、手を動かして試すことにした。

これがまたびっくりするほど簡単で、だいたい 3ステップくらいで ラズパイから AWS にデータを送りつけることができる。

ぶっちゃけ小学生でもできてしまうのではと思うくらいやさしい。

下図は、実際にラズパイから送られてきた Hello World を購読する様子である。

f:id:tercel_s:20210410210650p:plain

ラズパイから JSON が次々と AWS に送り付けられているのである。 そして MacBook Pro のブラウザからは、その様子がリアルタイムにモニタリングできる。

さて、こうなってくると集めたデータを捌く裏方の仕組みが作りたくなってくる。

そんなわけで、AWS Lambda をちゃんと勉強したいと思った。

短いけど今日はこれでおしまい。

Kubernetes はじめました

f:id:tercel_s:20210404190841p:plain

はじめまして Kubernetes

訳あって、この春から Kubernetesクバネティス なるものを使うことになった。

これは、ハリー・ポッターで例えると守護霊パトローナスの呪文くらいハイレベルで(伝われ!)、一朝一夕に使いこなせる代物ではない。

エクスペクト・パトローナム! 守護霊パトローナスよ来たれ!
守護霊の呪文

コンテナ技術と Kubernetes

閑話休題

Kubernetes とは何者かと訊ねると、ある者はコンテナオーケストレーションエンジンだと云う。

つまり、Kubernetes とは複数のコンテナを運用するための道具であるからして、そもそもコンテナが何なのかを前提知識として知っておく必要がある。

ゼロからキャッチアップしようとするとなかなか険しい道のりになりそうだが、千里の道も一歩からということで、今日は「なぜ Kubernetes なのか」について、コンテナという入り口から話していきたい。

そもそもコンテナとは

大雑把な話、コンテナとは「アプリケーションとその実行環境一式をパッケージ化したもの」と僕は理解している。

たとえば、僕が作った Web アプリケーションを、APサーバと一緒にコンテナ化する*1ケースを考えてみよう。 こうすると、いろいろと嬉しいことが起こる。

tercel-tech.hatenablog.com

実行環境の構築がラク

第一に、実行環境の構築がラクになる。

商用の Web アプリケーションは通常、評価環境や本番環境など、複数面の実行環境に展開ロールアウトするケースが多い。

コンテナ技術を利用しない場合、それぞれの環境に割り当てたサーバに Tomcat などの OSS をひとつひとつインストール & 初期設定をしないといけない。

このとき何らかの理由で評価環境と本番環境の構成に差異が生じた場合、アプリが正しく動作する保証は無い。

一方、コンテナ技術を利用する場合は、そのアプリを動かすために必要な環境のすべてがひとまとめになっているため、まるでバッテリー内蔵のおもちゃのようにどこへ持っていってもすぐにアプリを動かせる。

煩わしいバージョン合わせなどの手間が省けるし、「開発環境では動いたのに本番環境ではなぜか動かない」といった怪奇現象も起こりにくくなる。

もう少し掘り下げると、コンテナには Immutable Infrastructure という重要な概念がある。

これは、稼働中のインフラに手を加えることは許さない(e.g. 本番環境の DB にパッチ適用などもってのほか)という思想で、どうしてもインフラの構成変更をしたければコンテナから作り直して全置き換えする必要がある。

コンテナの中にまとめられたアプリは、その実行環境もまとめて時が止まり、勝手に環境がブチ壊れることはない。

コンテナは複製・起動・停止がラク

たとえば、僕が作った Web アプリが想定外の利用者数を記録し、急遽サーバを増設することになったとしよう。 まぁそんなことはありえないわけだが。

そのような場合、新しいサーバに僕のコンテナイメージを持ってきて、コンテナを起動しさせれば、その瞬間からアプリは動き出す。

全く同じ環境を別のサーバに構築し、それをワンタッチで起動できるのだ。

コンテナは互いに影響を及ぼさない

もう一つの利点は、コンテナは互いに影響を及ぼさないということである。

具体例を挙げると、1台のサーバで Tomcat を 2つ同時に動かすことなんかもできる*2

また、1台のサーバにアプリ A と アプリ B をデプロイし、それぞれが同じ OSS の異なるバージョンを利用している場合なども、それぞれ別々のコンテナで動作させることでヘンな事が起こらなくなる。

コンテナは後始末がラク(であると同時にコンテナ内のデータは儚い)

データベースや言語処理系などの中には、インストールは簡単だが、アンインストールが非常に面倒という始末に負えないケースが存在する。

これらもコンテナ化して利用すれば、不要になったときにすぐ潰して更地にできる。 コンテナを止めれば、そこにあったものが綺麗さっぱり跡形なく消え去る。

しかしこれは言い換えると、コンテナ内に保存したデータは永続化されないということにもなる。

たとえばデータベースやファイルサーバ用途のコンテナは、何もしなければコンテナの死と同時にその中のデータも道連れになる。これはまずい。

そのためどうしても永続化が必要なデータは、ボリュームマウントを行うなどしてコンテナと分離する形で管理しなくてはならない点に注意が必要だ。


コンテナ(手動)運用の課題

さて、ここまでのおいしい話を聞くと、実際にシステムをコンテナで運用したくなってくるだろう。

しかし実際の本番環境は、ただ単にシステムが動いてさえいればよいというわけではなく、とにかくシステムを止めないための工夫が必要になる。

そこで可用性を高めるため、複数のサーバにコンテナを展開しようという結論に至る。

だが、丸腰で運用を始めようとするといずれ様々な課題にブチ当たることになる。

コンテナの監視・復旧

どのサーバでどれだけのコンテナが動いているのかを人間が手動で管理するのは現実的ではない。

死んだコンテナを手動で復旧するのは(罰ゲームでやったことあるけど)しんどい。

コンテナの置き換え

先ほども書いたが、原則としてアプリケーションやそれに付随するインフラをアップデートするにはコンテナの置き換えが必要になる。

どのサーバ上でどのコンテナがどのバージョンで動いているかを一つひとつ確認して緊張感を持って切り替える作業などやっていられない。

サーバを跨いだデータの永続化

複数台のサーバでコンテナを運用しようとすると、永続データの置き場が問題になってくる。

前述のとおりボリュームマウントを利用すれば、コンテナとデータを分離し、データのみを永続化できる。

しかし、仮にコンテナを別のサーバに移し、ボリュームは元のサーバに取り残された場合、システムは意図した動きをしなくなる。


こうした課題を解決する一つのソリューションが Kubernetes である、という理解である*3

やや古い情報だが、Sysdig, Inc が公開している「2019 Docker Usage Report」によると、コンテナオーケストレーションエンジンのシェアは Kubernetes が約77%、次いで OpenShift が約9%、Docker Swarm が約5% であるという(『Kubernetes完全ガイド 第2版 (Top Gear)』より)。

そんなわけでだいぶ長々と書いてきたが、以上が Kubernetes を使う動機付けである。

なっげぇ……。

これだけ長々と話したけど、まだ Kubernetes を使う動機を語っただけに過ぎないという。

これ…… 仕事でやるの?

社内にはコンテナつよつよ部隊を自称するチームがいるので、さすがにガチインフラな領域は彼らに任せるよ。

でも勉強しないと死ぬねこれ。

確かに守護霊パトローナスの呪文と同じくらい難しそう。


取り急ぎお勉強用に強力な魔導書を買った。読まねば。

Kubernetes完全ガイド 第2版 (Top Gear)

Kubernetes完全ガイド 第2版 (Top Gear)

  • 作者:青山 真也
  • 発売日: 2020/08/07
  • メディア: 単行本(ソフトカバー)

*1:より正確には、「コンテナイメージを作る」と表現する。

*2:普通はできない。

*3:AWS が使えるならば ECS: Elastic Container Service や Fargateファーゲート を使えよというツッコミもあろうが、ちょっと会社の政治的な理由で Kubernetes を使わねばならんらしい。

ラズパイを組み立てて通電させた話

f:id:tercel_s:20210327201814p:plain

前回のあらすじ

ラズパイスターターキットを買った。

tercel-tech.hatenablog.com

しかし3月はあまりの忙しさに、Amazon の段ボールを開けることすら叶わなかった。

4月に入って一瞬だけ仕事が落ち着いたので、やっと箱から出すことに成功した。

小さな箱を開けると、そこには基盤があった

f:id:tercel_s:20210402224807j:plain

これはまず、何をすればいいの?

ヒートシンクを取り付けるよ。

冷えピタみたいなやつかな。

CPU は直接触ると火傷するレベルで発熱するし、最悪ねつぼうそうしちゃうので、、、

そうなの!?


モニタに繋ぐ

今回は小型のモニタも買ったよ!

ちなみにモニタのサイズはたった7インチなので、この商品画像に写っているおててはびとさんのものと思われます。

www

f:id:tercel_s:20210403215047j:plain
www.amazon.co.jp

メーカー名書いてないじゃん!

大丈夫なのコレ!?

中華製なので色々お察しの通りです。

ていうかコレ精密ドライバーが要るじゃん……。

ぉぉぅ……。

あと、ラズパイにHDMI-DコネクタとType-Cコネクタを取り付ける必要があるんだけど、固くて深く差し込めない……。

※ 下図 ❶

f:id:tercel_s:20210403214659j:plain

あまり力を入れると基盤を曲げちゃいそうw

しかもモニタにラズパイを合体させるときの固定位置が割とシビアで、ピンをへし折りそうになった。

そんなこんなで、なんとか1時間くらいかけて組み立てに成功した。

結局はんだづけは不要だったけど、いろいろハマりどころがあって苦労した。


通電と OS のインストール

電源入れるよ!

おぉ……!!

画面が映った!!!

なんか、初めてテレビがやってきたときの昭和の家庭みたいな感動が今ここに!

ロマンだね。

OS 入れるよ。

わくわく。

OS は Debian 系の Linux で、もともと Raspbian と呼ばれていたらしい。

ただ、現在は Raspberry Pi OS に改称されている。

まだ OS の名称が変更されて日が浅いせいか、Raspberry Pi 4B+ スターターキットの取扱説明書には旧称の Raspbian の表記が残っていた。

ひととおり設定すると、Wi-Fi に接続できるようになる。



取説のナビゲートもここまでっぽい。

あとは何をして遊ぶかだね。

温湿度センサーとか欲しくなってくるね。

やばいw おもちゃが増えるw

つづく。 かもしれない。

大学で落ちこぼれた話

大学生になったばかりの頃の話をしよう。

僕はかつて、とある商業高校*1から某国立大学の工学部に進学した。

種を明かせば、一般入試とは別口で、ごく少数定員ながら専門高校出身者向けの入試枠があり*2、僕はたまたまその門をくぐっただけに過ぎない。

すなわち僕は、普通の受験生が当然備えているであろう基礎学力を十分に身につけないまま大学生になってしまった。

置いてけぼり

入学して思い知ったのが、講義のレベルの高さと自分自身の力不足だった。

シラバスを見たときから厭な予感はしていたが、あんじょう、講義を聴いても内容をろくに理解できない。

特に数学と物理学は致命的で、僕ひとりがスタートラインに立ててすらいないことは明らかだった。

かけがえのない学友は確かにいた。 しかし、進学校出身の彼らと僕とでは素地がまるで違う。 皆、僕の遙か先を走っているような気がしてならなかった。

周りと同じ水準に追いつくことは他ならぬ僕自身の課題であり、強い隔絶感と密かなしゅう心を覚えたものであった。

五里霧

何はともあれ、自分自身の問題は自分自身でなんとかせねばならない。

せいきょうの書籍部で参考書を買い込み、朝な夕な愚直に読み漁った。

しかし無情にも講義の進度は速く、咀嚼している暇すらない。 いわんや予習など手が回るはずもない。 さらに数週間後には中間考査も迫っている。

時間もなく、気持ちに余裕もなく、常に焦りを感じていた憶えがある。

どこまでやれば追いつけるのか、それが見えないことがこれほどまでに苦しいのかと、真夜中にひとり、机の前で「もうダメだ」と破滅的な絶望感に襲われたことも一度や二度ではない。

そして焦る気持ちを上書きするように、がむしゃらに本を読んでは演習問題を解いた。

それから

そんな日々が続き、やがて雨の季節へと差し掛かる頃、あることに気付いた。

実際は、初年級で学ぶべきことは先人によってもはや既に体系化し尽くされており、まだ努力次第でなんとかなるらしいことがおぼろげながら見えてきたのである。

そういえば入学時のオリエンテーションで、工学部の学部長が『大学は、勉強を学ぶところではなく、勉強のやり方を学ぶところだ』みたいな話をしていたっけ。

初めは言葉のあやなのかと思い、さして意にも介さなかったが、あながけむに巻かれた訳でもなかったらしい。

結局、どうなったの?

テストでいい点取れた?

かなり際どかったけど、最終的になんとかなった。

大学では結局1単位も落とさなかったし、在学中に高度情報処理技術者資格 (NW) も取ったよ。

がんばったね。


以来、単に知識が足りないだけの場合は、関連する書籍を何冊か買い込んでそれらを横断するように読み込むパワープレイが定着してしまった。

もっと効率よく、時間と金を掛けずに学ぶ方法は他にいくらでもありそうだが、留年するよりマシだろうと割り切っている。

そして、いま

この春、ふたたび職場環境が変わり、これまで以上に「よく知らない技術」に触れる機会が増えた。

具体的には Docker や Kubernetes、また IoT × マイクロサービス開発など、もう一段、新機軸を目指して飛躍することになるだろう。

実感として、これまでのモノリス型システムの開発ノウハウはこの先通用しなそうだ。

まずは不足している知識のキャッチアップが必要だが、今まさに案件は目前にあり、待った無しの状況である。 なんとスリリングなことか。

学生時代のささやかな挫折経験がなければ、おそらく僕は今頃、旧態依然としたシステムエンジニアとして退屈そうにごはんを食べていたかも知れない。

あの日あのとき、きっと人生の「何か」が少しだけ変わったのだ。


土曜日の昼下がり、Kubernetes 本を読み耽っていたら、ふと若き日の思い出が甦ってきたので、心にうつりゆくよしなしごとを、そこはかとなく書きつくった次第である。

あやしうこそものぐるほしけれ。

*1:正確には、総合学科の情報処理課程だが、話を簡単にするため商業高校としている。

*2:試験で問われたのはせいぜい簡単な数学と英語の知識、そして面接くらいであった。

サイレントギターのこと

久々のギターねた

本日のお便りです。

※ 全然本日じゃない件

まじか。

まさかギター界隈でも名を馳せていたとは(違



どうやら、4年くらい前に書いた「ギターを買いに行った話」が未だに読まれているらしく、ありがたい限りです。

当時、全然弾けなかった頃に精いっぱい音を出している様子なども、音声投稿サイトにアップロードしていましたが、現在はそのサイトも閉鎖されてしまいました。

今もときどき弾いてる

あれからだいぶ経ったけど、今もときどき弾いてるよね。

はいー…… 拙奏で恐縮ですが、、

※ 音量注意


サイレントギターのすゝめ

昨今、「おうち時間」という言葉が生まれるなど、なにか一つインドアな趣味を見つける機会ともいえます。

そんなわけで、ふたたび僕が持っているサイレントギターについてちょっとだけ紹介しましょう。

サイレントギターのいいところ
  • 軽くて折り畳める
  • 普通のギターよりも音が静か
  • 一人で演じられる

なんと言っても、インドア派にも優しい電子楽器です。

楽器とか始めるのが怖いし、全くなにも弾けない状態の演奏をあまり人に聞かれたくない、という人にもぴったり。

一人で演じられる、という点を補足すると、ギターはそもそも、主旋律と伴奏を同時に奏でられる楽器なのです。

ふむ?

楽器の中には、基本的に単音しか出ないものもあるのです。

オカリナとか。

なぜそこでオカリナを例に出したw

いや、、、トトロつながりで。

それはそうと、ギターは、ピアノみたいに和音もいけるのです。

ほうほう。


五線譜が読めなくても大丈夫

ギターの楽譜は、五線譜ではなく、TABタブを使うのが一般的です。

たぶん五線譜より読みやすいと思う。

ふむ。

TAB譜には線が6本あって、それぞれがギターの1弦〜6弦に対応しているのです。

どの弦の、どこを押さえればよいのかを示しています。

なるほど。

音階ではなく、押弦の位置と弾くタイミングが分かる感じなのか。

指の動きに直結する譜面になっているので、ピアノよりも弾きやすいと思う。 ピアノ弾いたことないけど。


楽器未経験者にこそおすすめ

初めての楽器にギターを選ぶのは、ぶっちゃけどう思う?

やっぱり無謀?

いや、そんなことはないと思う。

特に練習しはじめの頃は、毎日のように、「昨日できなかったことができるようになる」体験を味わえるよ。

ギターのいいところ教えて!

自分で音が出せること……かなぁ。

同じ音でも、聞くのと奏でるのとでは全然違うよー。

それなら、べつに他の楽器でもよいのでは?

さっきも言ったとおり、ギターは一本で主旋律と伴奏を同時に奏でられる和音楽器なので、複雑な音を自分の手で生み出しているという不思議な感覚を楽しむことができるのです。

なるほど。

あと、アコースティックギターめちゃくちゃ癒し系の音が鳴るので、うれしい。

もちろん電子楽器なので、どうしてもなまおとには敵わないけど…

いいね。


そんなわけで、ギターたのしいよというお話でした。

なしくずし的におしまい。 めでたし。

急にラズパイが欲しくなってぽちった話

f:id:tercel_s:20210327201814p:plain

しょげないでよベイベッ

おいどうしたw

このあいだ、めっちゃネガティブな日記を書いてたじゃん。なにあれ?

まぁ、↑ に書いた通りですよ。

しかもどさくさに紛れてリトルナイトメア2 のネタバレまでするんじゃねーよw


初めての Raspberryラズベリー Piパイ

ここから今日の本題なのですが、春から参戦するお仕事の一つに、ラズパイで IoT ごっこという案件があるのです。

※ これは前々から決まっていたことで、今回の異動とは関係ないよ。

まじか。

長らく Web アプリ開発が主戦場だったからね。
新章突入だね。

それで先日、案件の紹介がてら、会社のラズパイを触らせてもらいました。

そしたら、思いのほか楽しかった。

いいから落ち着け。

いやぁ、、 今までラズパイに興味がなかったのに、いざ触ったら欲しくなるね。

善は急げで、ラズパイのスターターキットと O'reilly から出ているクックブックを買っちゃった!

おー!

いつ届くの?

たぶん明日。

ラズパイ is 何?

※ 補足の画像等を用意できなかったため、会話のみでお楽しみください

そもそもラズパイって何者なの?

本体はコレ。

剥き出しの基盤みたいなの。

ふむ。

で、OS はこの SD カードに入ってるらしい。

キーボードとマウス、あとモニタはそこら辺に転がっているものに繋ぐ。

あ、なんかすごいユーザーフレンドリーな GUI が表示されてる。

真っ暗なターミナルにひたすらコマンドを打ち込む系かと思ってた。

C++ とか Python とか、Node.js とか、なんかプログラムを作ってラズパイ上で動かして遊べるっぽい。

これはいいね。

ちっちゃくてかわいいし、夢が詰まってる。。。

ねー。

欲しくなったでしょ?

しかし使い途がわからんw


おまけ: なつかしの Arduinoアルドゥイーノ

そういえば大昔、よく似たおもちゃを持ってたっけ。。。

たしか、Arduino とかいうの。

ほう…。

それは初耳。

ぉぉぅ。 映像のクオリティから時代を感じる(婉曲表現)。

敢えて、そういう味を出すためにトイカメラで撮ったのだと思う。

まだ全然、学生だった頃だねこれ。

そんな遊びをしていたとは。

てか、よくこんな映像が残ってたね。

Arduino は、大学を卒業して上京するときにも持ってきたのだけど……、結局、仕事が忙しすぎて、全然遊ばないまますっかりおもちゃ箱の底に。

好きだったはずのことを、忙しさにかまけていつの間にか忘れてしまっていたんだ…。

なんだか、さみしいね。

いやホントそれ。 でもすっごく懐かしい気持ちになってきたよ。


やりたいこと、やったもん勝ち

つらいーとーきはいつーだってー そばにーいるーからー

おいやめろ、JAS█AC が来るぞ。

あーでもラズパイいいなー楽しそう。

なんか楽しいのができたら見せて!

了解。

まぁ期待せずにお待ちください。

つづく、かも知れない。

異動の内示

今日は異動の内示が出た。

思うところが多すぎて、正直、心が晴れない。

話の始まりは1年ほど前に遡る。 当時、社内に新たな部署が設立され、そのスタートアップメンバとして僕も参入したのであった。

あれから僅か1年。 自分の中ではそれなりに頑張ってきたものの、今回の異動では、人材ローテーションの名のもとに、今の上司のもとを離れ、新任の管理職の下に就くことになった。

誤解をおそれずに言うと、「なぜ僕なのだろう」という猜疑心にも似た気持ちなのである。

リトルナイトメア2で、あれだけ信頼関係を築いていた主人公モノとシックスが、最期に取り返しのつかない形で破局を迎える衝撃的なストーリーにいたくショックを受けたものだが、なんとなく今の気持ちはそれに近いかも知れない。

f:id:tercel_s:20210325200126j:plain:w500


── 前向きな考えと、後ろ向きな考えが交錯する。

もし僕が仮に上司の立場だったとしよう。 自分の部下が6人いて、そのうち3人だけ残してよいと言われたとき、どういう基準で残す人を選ぶだろうか、という問いだ。

何のしがらみもないならば、普通に要らん順に3人切り捨てるだろう。

では、「あなたの部下から3人選んで、新任の管理職の下につける」と言われたら、どういう基準でその3人は選ばれるのだろう。 さすがに要らん人間ばかりを押し付けたりはしないだろうが、さりとてお気に入りをみすみす手放す馬鹿な真似もしないだろう。

反対に、自分が新任の管理職だとして、「あの中から3人だけ選んで自分の最初の部下にしてよい」と言われたら、どうやって選ぶのだろう。

新人の頃の思い出

話は変わる。 と見せかけてさほど変わらないので引き続きお付き合い願いたい。

思い起こせば、あれはまだ入社して 1〜2週間めくらいだった。

新人のお仕事といえば、朝から夕方まで研修を受けて、定時に帰宅することだった。

とある資格の試験対策講座でのできごと。 その日の講師の一言が、今も印象に残っている。

『もしあなたが採用担当者で、募集枠1名のなか、最終選考に2人が残っているとしよう。 学歴も能力もほぼほぼ同等で甲乙つけがたいとする。 でも、片方は難関資格を持っていて、もう片方は無資格だとしたら、どっちを採る?』という、あからさまに誘導的な問いではあった。

しかし一つの真理として、人を評価する立場になったとき、必ずなんらかの序列をつけて、ときには下位の人間を切り捨てなければならないこともあるのだと悟った。

そして時間を現在に戻すと、こたびの人事ゲームの舞台裏でどのような駆け引きがあったかは知る由もないが、おそらく、僕は、今回は生き残れなかったのだろうな、、、と、卑屈な思いが心の奥底に沈殿している。

僕たちはどう生きるか

だいぶ話がとっ散らかってきたな。

脱線ついでに、なぜここにこんなことを書いているかと言うと、珍しくネガティブな情動に駆られたので、せっかくだから記録に残しておこうと思った次第である。

何はともあれ、とにかく生きねばならない。

まもなく新体制に移行する。

来年度は、こんな瑣末なことで一喜一憂したりせず、自分が本当に大切だと思う価値観を貫けるような、ぶれない人間でいたいものだ。

Copyright (c) 2012 @tercel_s, @iTercel, @pi_cro_s.