S3 のお勉強(その3)

  • バケット名はグローバルレベルで一意である必要があるが、S3 自体はリージョン単位でのサービスである

意外とハマる

バージョン管理

  • バージョン管理を一旦有効化すると、無効化することはできない(停止: suspend することは可能)
  • バージョン管理を有効にした場合、最新ファイルを削除しても旧バージョンは残る
  • バージョン管理はバケット単位で設定可能
  • ライフサイクル管理と組み合わせて使用する


ライフサイクル管理

  • 128KB 以上のファイルがS3 からS3-IA に移動される
  • デフォルト30日でS3-IA に移動し、さらに30日でGlacier に移動する
  • ライフサイクル管理ではバージョニングは必須ではないが、バージョニングを使用すると現バージョンと前バージョンを管理できる


S3 Transfer Acceleration

  • CloudFront のエッジロケーションを利用してネットワークの高速化が可能になる

もうちょっと続く

S3 のお勉強(その2)

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

  • 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)

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 のお勉強を始めている。

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



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 / クロスアカウントアクセスとかもあるけど今回は割愛。

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と被ってたんで、もし通っちゃったらどうしようかとヒヤヒヤしてました。ごめんメンバーの皆さま。
 八番目の予選通過がなぜか「6」になってたのは見なかったことにします

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 興味ないのか? -> 実は…