S3 のお勉強（その2）

AWS

　昨日書ききれなかったことをつらつらと

  • S3 のbucket = Windows のフォルダーだと思っておけば良い。
  • バケット名はグローバルで（リージョン内で、ではない）一位でないといけない。
  • バケットへのファイルアップロードが成功すると、HTTP レスポンスとして200が返る
  • S3 の暗号化は以下の通り
    1. Client Side Encryption
    2. Server Side Encryption
  • Server Side Encryption には以下の三種類がある
    1. Server Side Encryption with Amazon S3 Managed Key (SSE-S3): AES-256相当
    2. Server Side Encryption with KMS (SSE-KMS): AWS のサービスであるKMS を利用した暗号化
    3. Server Side Encryption with Customer Provided Keys (SSE-C): ユーザーが用意した暗号化鍵を使用した暗号化。鍵の管理をユーザーで行う必要があるので煩雑だけど、管理したい人には嬉しい
  • バケットへのアクセス制御は、バケットACL を使うか、バケットポリシーを使用する
  • デフォルトでは、バケットおよびその中にあるファイルはプライベートモードのため読み書きできない

ちょっと長くなりそうだから続きはまた明日。

AWS のお勉強（S3）

AWS

S3

　EC2 と並んでメジャーなAWS コンポーネントではないだろうか。オブジェクトストレージとして静的ファイルの格納に使用したり、場合によってはS3 のみでweb ページを作成することができる（自由度は低い気もするが）。


　S3 の特徴は以下の通り

  • ブロックベースストレージではない = dropbox みたいなもので、OSやアプリをインストール対象ではない
  • オブジェクトストレージ = ファイルをただアップロードするだけ。実際には静的ファイルを置くことが多い
  • リージョンに限られない、ユニバーサルなサービス
  • ファイルのアップロード成功時にHTTPレスポンス200を返す
  • 新規アップロード時の一貫性は保証するが、上書き、削除時の一貫性は保証しない（古いデータにアクセスできてしまう可能性がある）
  • 実態はKVS で、以下の内容を持っている

- key : データの名前
- value : データの実態
- version id : データのバージョン管理に使用するデータ
- metadata : 格納したデータに関するデータ
- subresources : アクセス制御リストや、bittorrent に対応するためのデータ

  • 一般に、99.99%（公称99.9%）の可用性を誇る
  • 同様に、公称 11 x 9s の耐久性を誇る
  • S3 の種類

- S3 : 高耐久性、高可用性、頻繁なアクセス向き
- S3-IA : 高耐久性、高可用性、頻繁ではないアクセス向き（読み出し容量ごとに課金）
- Se-RRS : 低冗長化ストレージ、耐久性は99.99%。Glaicier から取り出したデータや再生性可能なデータの保管に利用
- Glacier : データアーカイブの保管先。低コストだがデータの取り出しにコストと時間が必要

  • Glacier は戻しに3〜5時間が必要になる

AWS のお勉強（IAM）

AWS

　昨年の九月に仕事を辞めて以来、ブラブラしていたのだが、そろそろ腰を据えて社会復帰の準備をを考え始めた。とりあえず、リハビリがてらAWS のお勉強を始めている。

　メモ代わりにここに記録を残していこうと思う。



IAM (Identiry Access Management)

　IAM というのは、AWS コンソールにおける権限管理の仕組みである。ユーザーA にはS3 の読み取り権限のみを、ユーザーB には管理者権限を与える、などの操作が可能である。元々、AWS 利用申請が受理された時点では、root ユーザー（これは申請時のメールアドレスを使用してログインする）のみ利用可能であるが、名前の通りなんでもできるアカウントであるため、root ユーザーは極力使わず、IAM ユーザーを使用することが強く奨められている。
　（ただし、CloudFront キーペアの作成など、一部作業はroot アカウントでないとおこなえないため、それら作業の時にはroot ユーザーを使用する必要がある）


　主な特徴は以下の通り

  • 1 AWS アカウントで5000ユーザーまで作成可能
  • 1 IAM ユーザーは10までのグループに所属できる
  • 1 AWS アカウントで100グループまで作成可能
  • ユーザーは、文字通り、AWS Console を利用するユーザー個々人を指す
  • グループは、Administrator, Developer, Designer の用に作成し、ユーザーと紐付ける。グループにポリシーをアタッチすることで、個々のユーザーを作成するたびにポリシーやロールをアタッチする煩雑さを減らす
  • ポリシーはAWS のリソースに対する権限をJSON 形式で記した者で、これをグループやロール、ユーザーにアタッチすることで権限を付与する
  • ロールはポリシーの集合で、これを作り、付与することで、一つ一つポリシーをアタッチする煩雑さを省略する
  • IAM の管理はグローバルにおこなわれ、特定リージョンのみに有効なIAM ユーザーなどの作成はおこなえない


　その他、認証情報の有効期限とかSwitch Role / クロスアカウントアクセスとかもあるけど今回は割愛。

■

RHEL

yum update を実行したときに、

** Found 17 pre-existing rpmdb problem(s), 'yum check' output follows:
device-mapper-1.02.117-12.el6_9.1.x86_64 は device-mapper-1.02.117-12.el6.x86_64 の複製です
device-mapper-event-1.02.117-12.el6_9.1.x86_64 は device-mapper-event-1.02.117-12.el6.x86_64 の複製です
device-mapper-event-libs-1.02.117-12.el6_9.1.x86_64 は device-mapper-event-libs-1.02.117-12.el6.x86_64 の複製です
device-mapper-libs-1.02.117-12.el6_9.1.x86_64 は device-mapper-libs-1.02.117-12.el6.x86_64 の複製です
httpd-tools-2.2.15-60.el6.centos.6.x86_64 は httpd-tools-2.2.15-60.el6.centos.5.x86_64 の複製です
kernel-firmware-2.6.32-696.16.1.el6.noarch は kernel-firmware-2.6.32-696.13.2.el6.noarch の複製です
kexec-tools-2.0.0-307.el6_9.1.x86_64 は kexec-tools-2.0.0-307.el6.x86_64 の複製 です
kpartx-0.4.9-100.el6_9.1.x86_64 は kpartx-0.4.9-100.el6.x86_64 の複製です
libblkid-2.17.2-12.28.el6_9.1.x86_64 は libblkid-2.17.2-12.28.el6.x86_64 の複製 です
libuuid-2.17.2-12.28.el6_9.1.x86_64 は libuuid-2.17.2-12.28.el6.x86_64 の複製で す
lvm2-libs-2.02.143-12.el6_9.1.x86_64 は lvm2-libs-2.02.143-12.el6.x86_64 の複製 です
mysql-community-client-5.6.38-2.el6.x86_64 は mysql-community-client-5.6.37-2.el6.x86_64 の複製です
mysql-community-common-5.6.38-2.el6.x86_64 は mysql-community-common-5.6.37-2.el6.x86_64 の複製です
mysql-community-libs-5.6.38-2.el6.x86_64 は mysql-community-libs-5.6.37-2.el6.x86_64 の複製です
ntp-4.2.6p5-12.el6.centos.1.x86_64 は ntp-4.2.6p5-10.el6.centos.2.x86_64 の複製 です
ntp-4.2.6p5-12.el6.centos.1.x86_64 は次の要求が不足ています:  ntpdate = ('0', '4.2.6p5', '12.el6.centos.1')
util-linux-ng-2.17.2-12.28.el6_9.1.x86_64 は util-linux-ng-2.17.2-12.28.el6.x86_64 の複製です

なんてエラーが出てきたのでググってみた。

結論
rpm 情報を格納する DB (rpmdb) にレコードの重複があった。 package-cleanup --cleandupes を実行した後で、再度 yum update を実行すると、無事アップデートできた。
重複の確認は rpm -q パッケージ名 してやればわかる。

中京テレビハッカソン”HACK-CHU!”で予選敗退してきた

　昨秋笹島に移動した中京テレビさん（日テレ系列）が主催するハッカソン、"HACK-CHU!"の予選（アイデアソン）に参加し、華々しく散ってまいりました。


　はじめに
　もうまとまってます。


　参加に至る経緯
　毎度のごとくきっかけは「名古屋ギークバー」。1/30の会だったかな？　中京テレビの技術推進局の方がいらしていて、「今度ハッカソンやるんですよ」なんて会話からの「かわいさん出れば？」というどみにをん525さんの無慈悲な一言。ま、まぁ、ハッカソンなら自信ないけどアイデアソンならまだなんとかね……。というわけでした。


　準備
　公式ページに、利用可能なAPI を確認。言うてもアイデアの段階であまり技術詳細をつめるのは個人的には好きではないので流し読み。まぁぶっちゃけ「どっかの企業がIAAS提供してればなんでもできるよね」くらいに思ってました。そもそもこの週は肉体的に疲れが溜まっていたようで、金曜日にはぶっ倒れたまま二十時間くらい寝っぱなしだったりしたんですが、なんとか当日には体調も快復。そして安定の遅刻。


　当日　〜チームビルディング
　到着時点では、API 協賛企業による、自社API の説明中でした。たしかKDDIさんのtwilioだったかな？　そこから幾つかの説明をうかがった後、アイデア出しからのチームビルディング。確かこんな流れだったはず。

  1. まずは個人でポストイットに「親」「自分」「子」の「朝」「昼」「晩」の行動や感情を書き出す
  2. テーブルの皆でそれを大まかに分類する
  3. そこから連想した「これあったら良いな」というものを書く（スケッチブックから一枚取り、四つ折りにして四つの案を出す）
  4. テーブルの皆に↑を説明して、フィードバックをもらう
  5. ブラッシュアップしたアイデアを渾身で描き上げる
  6. 仲間を募る or 面白そうな案に乗っかる

　僕は、自分では「世代を超えた共通の話題検索エンジン」っつーのを考え、イマイチ自分でもピンとこなかったので、早々に別参加者さんの"GET OUT MTG"というネタに乗っかることにしました。「ダラダラ会議をぶっ潰す」というのに共感を覚えたのと、説明を見た時に、「コレの1:05〜2:55的な絵」が見えたからです。某国大統領が昔やってた「U R Fired!!」みたいな絵がバッチリと。やっぱり着地点が見えると、経路の探索に専念できるし、良いですね。


　あと、個人的にブラックな感じのも考えつきましたが、それは秘密です。


　当日　〜お弁当
　上記のまとめをごらんください。例。美味しゅうございました。タダ飯サイコーっ！！


　当日　〜午後の部
　今回初めてハッカソン/アイデアソン的なものに参加して一番ビックリしたのが「時間がない」ということでした。お昼をいただいた後、発表資料（今回はスケッチブックに描いた字と絵で発表）の作成にかかったのですが、その時点で残り時間は一時間あるかどうか。二時間あっても足りるかどうか。いやいやいやいや、面白いじゃぁないの。あーでもないこーでもないと言いながら進めます。と、いいつつ僕は、途中で投げちゃった部分もありますが。
　とは言え、他人の意見を聞けるのは面白いですね。今回で言うと、サービス名を"Happy MTG"（音だけだったので、当時書記をしていた僕が「はっぴぃみぃてぃんぐ」にしちゃった。ほら、むかし居たでしょ、そんなグループ「はっぴいえんど」って……）と提案してくださった方がいたこと。「ミーティングとハッピーって縁なさそうじゃない？」「確かに！」そんな感じでした。
　そして僕は吐き出すものを全て吐き出した後、貝になりました。コミュ障っちゅうか、コミュニケーションに努力しないよね。ホント……。


　当日　〜発表を聞いたりしたり
　面白い。ふわっとしていたとは言え、同じお題をもらってもこんないろいろ考えつくものなんだなぁ。と感心しきりです。独身アラフォーには考えもつかない家庭の話とか、「爪が長いとキーボード打ちにくいしボルダリングもできないし」とか考える人間には考えつかないバーチャルネイルとか、おもろい。ぶっ飛びすぎてた裸族のクラブこと「クラブロ」、まさか名古屋でこんな頭のおかしい（褒め言葉）ネタが出てくるとは……、すごいなぁ。
　逆にイエナウは「時間の無駄を削ぎ落とす」という（今回の発表の中では）珍しく、ビジネスよりの話でこれまたおもろい。
　まぁまぁ何はとまれ、予選通過した皆さま、本線頑張ってくだしあませちくしょーっ！　賞金欲しかったよおおぅ。


　備考
　発言の責任は取る。
　コレ多分僕だ。
　コレ現在進行形でツラい。「アンタ頼りにならんからユーキャンに頼むわ」 -> 「ユーキャンに繋がらんのだけど」とかバターン死の行進かよ。
　全般的にpepperくんの人気がすごかった＆VRが造形大くらいしか取り扱ってなかった。逆張りチャンスあるかも？
　発表後どみにをん525さんから「あれは☓☓☓へのアラートとして行けそうだったのに、なんであーいう発表になっちゃうのかなぁ」と言われるなど。いーんですよ！　とりあえず、「気持ちよく人の前で話せる体験」をしましょーよ！
　実は本選の日が、JAWS DAYSと被ってたんで、もし通っちゃったらどうしようかとヒヤヒヤしてました。ごめんメンバーの皆さま。
　八番目の予選通過がなぜか「６」になってたのは見なかったことにします。

DNS に関するRFC を読む勉強会に参加してきた

　題名の通り、RFC1034 を読みつつ、その内容を解釈する勉強会に参加してきました。まぁ詳細はtogetterにまとまっているのでそちらをどうぞ。


　今年に入って三回目の勉強会でようやく勉強できたかなぁ（初回: #v6tokai の新年会で楽しく飲酒＆学生を引きずり回す。二回目: #nagoyarb03 で太鼓、他を担当する。三回目（今回）: 一参加者として、DNS のお話をうかがう（<-New!）という感じ。


　参加に至る経緯
　元々、首魁の鈴木センセー＠中京大学 が主催する #v6tokai とか、 DNS 温泉（ハッシュタグは都度違うので省略）とかにお邪魔していたので、軽〜いノリで今回にも参加しました。あと、心の奥底では、過去にRubyコミッターの某氏が酒の席で言った「ガチなITエンジニアはRFC を息をするように読んでいる」という発言が気にかかっていたのかも知れません。


　当日
　「事前に読んどけよ」と言われたけど、2.2章までしか読めないまま参加。ラッキー（はぁと）だったのは、今回、インフラガールさん（ @infragirl755 ）がいらしていたことを意識したのか、首魁が微に入り細に入った解説をしてくださったことです。一部からは
「丁寧すぎでは？」という意見も出ていましたが、個人的にはこれはこれで面白かったです（not funny but interesting）。
　っていうか、ITエンジニアを名乗るなら、RFC 読まなきゃダメだな、と痛感させられた会合でした。


　懇親会
　は、名古屋地下鉄鶴舞線でﾁｮｯﾄｻｷﾆｲﾄﾞｳｼﾃ、鶴舞駅近くの串太郎と言うお店。安い！　あと、カレー味の串はここにもあったんだ！　という感じ。
　かみやさんがインフラガールさんを #IHANet @新宿に誘うのに釣られて、その場で亀戸二泊三日の予約をしてしまうかわいさんであった…。いや〜、久々にベアーズクラブに行けるぞー。たーのしみー。
と言った感じでしゅーりょー（銅鑼）


　二次会
　鶴舞から地下鉄で一駅、東京で言えば御茶ノ水から秋葉原くらいの距離を歩いて、上前津のお店、「ルナビアンカ」へ。ウィスキー飲み放題\2,000-とか頭おかしい。経営大丈夫なの！？　
　鈴木センセー、のえるさん（@pO_0q）と濃ゆい話をして大変満足いたしました。


　全体的な感想
　元々僕は、「DB(Oracle Database)小父さん」からの「サーバーエンジ『にゃーん』」でしたので、ネットワークはほぼ触ったことが無かったんですよね。せいぜいが、DBストレージをつなぐSAN スイッチを触ったくらい。とは言え、この勉強会は、僕が帰名してからかなりお世話になっている（並び立つのは #geekbar ）で、会う人話す人から受ける「おっしゃ僕も頑張らにゃぁ」感がいや増す、なんとも刺激を受ける素敵な会（僕にとって）です。
　今回は特に、RFC という、「the Internetの原理原則」、もっと言えばそれ以前でもある、現在「当たり前」になっているネット環境の起源みたいなものに触れるという、貴重な機会でした。というか、僕も1994年くらいからPC（PC-98互換機）触って、MS DOS 3.3 -> MS-DOS 5.0 w/Win 3.1 -> Win 95 w/Internet -> Win 98時々FreeBSDとかVine Linux -> 酷いアレ -> Win 2000 -> Win XP -> 諸々を経て、今も情報システムに関わっているんだから、小さな声でも、歴史を伝えていかなければいけないなぁ。と改めて思いました。っていうかまさか今更「草の根BBS 」とかの話をできるとはw。当時はえっちい会社が独自BBS とか持ってたんだよねぇw。
　真面目モードに戻ると、RFC は、歴史をたどることのできる良い資料（他にも往時のNewsGroupとかMLとかありますけど）ですし、自分のペースで読んで、「英語コンプレックス」を解消する意味でも良手なので、今後、個人的に読んでいきたいと思いました。旧 -> 新で読むか、新 -> 旧と読むか悩みますが、とりあえず、タイトルを見て、「面白そう」と思ったものから読んでみようかな、などと思いました。




　お前DNS 興味ないのか？ -> 実は…

名古屋Ruby会議03で太鼓を叩いてきた

　昨日、大須演芸場で開催された名古屋Ruby会議03にスタッフとして参加し、舞台上手で大太鼓、小太鼓、鐘、拍子木、銅鑼を担当しました。


　※　技術の話は一切出てきませんのでご容赦下さいませ。


　きっかけ
　毎週月曜日、新栄では「名古屋ギークバー」というイベントが開催されているのですが、2/5 の開催（テーマなし会）時、主宰のどみにをん525（ @Dominion525 ）さん（名古屋Ruby会議03の首魁でもある、多分……）に、「手伝いましょか？」と話を振ったところ「太鼓叩ける人が欲しいんだよねぇ。出囃子はCD使うけど、鳴り物はあるから使いたいんだよねぇ。kwy さん三味線経験者だし、叩けない？」という無茶振りで返されるというね。


　準備
　まぁ「あの」大須演芸場にスタッフとして入り、裏側を見れると言うのは貴重な経験。ということで、前向きに対処いたしたく候、ってなわけで、愛知県立図書館で出囃子のCDを借りたり、youtubeやニコ動で動画を見たりしました。談志家元…（ https://www.youtube.com/watch?v=Jhr19PLHgng ）。まぁ、このあたり（https://www.youtube.com/watch?v=Hg4Mvam7icw）が非常に参考になりました。
　出囃子はアドリブでやるとして、とりあえず、一番太鼓、二番太鼓、中入り、追い出しを覚えねばということで、持ち運び用PC（最近大須のイオシスで32bit Win7マシンを手に入れた）と、スマフォに入れて常時聴いていました。脊椎反射で叩ける用にしておかないとイカン。詰め込みすぎていっぱいいっぱいになった時は、息抜きに落語を聞いたりしました。ゆかおさん（ @yucao24hours ）にも伝えましたが、「鮫講釈」、オヌヌメです。僕は談志家元がひとり会で「二人旅〜桑名舟」と題して行った作品が好きです。もちろんCDも持ってます。藤沢に住んでいた頃、長後街道沿いにあったBOOK OFFで買った記憶ががががが。
　結果として頭の中では常に太鼓がなってましたね。「ドン、ドン、ドン」、「スッチャラスタスタスットントン」、「ドロドロドロドロ〜。ドン、ドン、ドン、ドドドン」みたいに。これが良かったのか悪かったのかはご来場いただいた皆様のご判断におまかせいたします。


　前日
　どみにをん氏から「朝8:30集合ね」と言われていたので、開場最寄りの「大須観音」駅から一駅隣りの、「上前津」駅からほど近い、「名龍」さんを予約。素泊まり5500円は、東京のビジネスホテルに慣れた身としてはお手頃価格、いや、激安案件でした。風呂トイレ共用とは言え、風呂24h 利用可、wifi完備は、個人的に評価高いです。あと、お時間ある時はご主人とお話ししたり、お子様と戯れたりすると楽しいですね。
　PCで「一番太鼓」「二番太鼓」「中入り」「追い出し」をループ再生させて、それをイヤホンで聴きながら就寝。


　当日
　安定の遅刻魔は8:45に会場入り。実物使っての練習は9:30の開場までしかないので、鳴り物は何があるかを確認した後、長バチ（祭り囃子に使うぶっといやつではなく、ほっそ長いバチ。ドラムスティックに近い）を二、三振り。あっという間に開場時間。気合いを入れて一番太鼓を叩きます。「からからからから」からの「どーんどーんどーんと来い」、千客万来を祈念して、心を込めて叩きました。以降は完全アドリブ。昼休み中のスクリーンチェック中におおど（江戸落語では大太鼓をこう呼びます）を叩いたり、二番太鼓の出番が無くなったので、中入り後に使ったり、演者様、お客様の反応に合わせて茶々を入れたり、まぁ素人としては頑張ったほうだと思います。とは言え評価はやっぱりご来場いただいた皆さまにおまかせいたします。


　終演後
　やっぱり「アドリブで演者に併せて鳴り物を」となると、話をゆっくり聴いている余裕なんざぁないわけで、今週末辺りにでもゆっくりと発表資料を眺めようと思います。あとはコレ（ https://twitter.com/kwy8791/status/831515090738364416 ）に尽きる。ありがたやありがたや…。
　また、今回は私の経験も踏まえて、江戸落語風の鳴り物になりましたが、機会があれば上方風の鳴り物にも挑戦してみたいです。ちょっとエンジニアとしての自覚に欠けてますね。


　寄席太鼓について
　このサイト（ http://www.rakugo.or.jp/yosetaiko.html ）が詳しいです。


　パブ
　東海地方で「素人でいいから鳴り物欲しい」と言われたらご相談下さいませ。太鼓、鐘、銅鑼、拍子木までなら伴奏があればアドリブでなんとかします。三味線は一ヶ月ほど時間を頂きたい次第です。




※　とりあえず脱稿。巧緻より拙速で。