読者です 読者をやめる 読者になる 読者になる

ニクニクドットミー

カッコいいおっさんを目指すエンジニアの厳かなブログ

スポンサーリンク

【AWS】今更ながらDynamoDB入門

AWS DynamoDB

f:id:maaaato:20151223215351p:plain
NoSQLデータベースであるDynamoDBに今更ながら入門してみようと思います。
こちらの記事を参考に手を動かしながら、感覚をつかもうと思います。
AWS再入門 Amazon DynamoDB 編 | Developers.IO

また、DynamoDBにはハッシュキー、レンジキーといった概念があるので、それらを理解する為にこちらを参考にさせて頂きます。

Amazon DynamoDBはマネージドなNoSQLデータベースです。RDBMSとは違い、リレーションやトランザクションといった概念がありません。しかし、キャパシティが自動でスケールするなど管理する項目が少ないのが特徴です。また、RDSとは以下の点が違います。

RDS DynamoDB
一貫性 強力 結果整合なので基本的に弱い(強整合性指定も可能)
原子性 ある ない(同じアイテム内の更新であれば可能)
検索条件 SQLのWHERE句で自由自在 事前指定のキーまたはインデックスのみ
可用性 メンテナンスウィンドウあり 基本的に常に利用可
拡張性 スケールアップのみで天井が低い シャーディングによるスケールアウトが可能

結果整合性はS3と同じですね。データ更新直後はデータが取得できなかったり、古いものが取得される可能性があります。

続きを読む

【AWS】SQSをただただ触ってみただけの話

SQS AWS

f:id:maaaato:20151223134852p:plain
AWS最古のサービスSQSを今回は触ってみます。

SQS(Simple Queue Service)とは

Amazon Simple Queue Service(Amazon SQS)には、コンピュータ間で送受信されるメッセージを格納するための、信頼性の高いスケーラブルなホストされたキューが用意されています。Amazon SQS を使用することによって、さまざまなタスクを実行するアプリケーションの分散コンポーネント間で、データを簡単に移動させることができます。

キューイングサービスですね。どういう用途に使うかというと、例えば処理を切り離したい時に使う事が出来ます。
DBのデータ更新系の処理だとして、リクエストを受け付けて、その後DBの更新を行うとし、このDB更新に時間が掛かるとします。更新が完了するまでの間レスポンスが帰ってこない状態になってしまうと思います。これを受付と更新とで切り分ける時にキューイングの出番です。
受付処理の時にキューイングに更新依頼きたよーとキューにメッセージを入れます。キューにメッセージを入れたら、レスポンスを返却します。その後、ワーカーがキューのメッセージの有無を確認し、メッセージがあればDBを更新します。 キューイングを用いると処理を切り話す事が出来ます。

キューは、データの生成と保存を行うコンポーネントと、データを受信して処理を行うコンポーネントの間のバッファーとして機能します。つまりキューは、消費者(Consumer)の処理スピードよりも生産者(Producer)が早く作業を生成したり、生産者と消費者がネットワークに断続的に接続されている場合などに発生する問題を解決します。

続きを読む

【AWS】Elastic Beanstalkをただただ触ってみただけの話

AWS Elastic Beanstalk

f:id:maaaato:20151220181756p:plain
今回はAWSのサービスの一つであるElastic Beanstalkを触ってみたいと思います。

Elastic Beanstalkとは

ELB,EC2,AutoScalingがセットになったPaaSです。アプリエンジニアは作成したアプリケーションをElastic Beanstalkにデプロイするだけでサービスを展開出来るので、アプリ開発に集中する事ができます。 現在(2015年12月時点)サポートしているのはJava、.NET、PHP、Node.js、PythonRuby、Go、Dockerとなっているようです。またElastic Beanstalkで使えるOSはAmazonLinux、Windows Server2012が利用可能です。Ubuntuを普段使っているので、ちょっと残念です。

Q: AWS Elastic Beanstalk では、どのオペレーティングシステムが使用されますか? AWS Elastic Beanstalk は、Amazon Linux AMI および Windows Server 2012 R2 AMI で実行されます。どちらの AMI もアマゾン ウェブ サービスによってサポートされ、管理されます。これらは、Amazon EC2 クラウドコンピューティングのための安定性、セキュリティ、およびパフォーマンスに優れた実行環境を作るように設計されています。

AmazonLinuxだとローカルに環境が作れない(Vagrantなどで)ので、Dockerでデプロイするのが良さそうです。Dockerであれば、ホストOSは気にせず(あまり)にローカルに環境が作れるので、Elastic Beanstalkを使う場合は、Dockerが良さそうです。

続きを読む

初めてQiitaにアドベントカレンダーを作ってAutoScalingの話を投稿しました

アドベントカレンダー AutoScaling

皆さんアドベントカレンダーやってますか??

qiita.com ※投稿したアドベントカレンダー一日目の記事

Qiitaというエンジニア向けの情報サイトには毎年恒例のアドベントカレンダーというものがあります。これは12/1 ~ 25日まで、あるテーマに沿った記事を毎日交代で書いていくものです。同じ人が複数書いても問題ありません。テーマはそれぞれで、言語であったり、AWSであったりと多岐にわたります。
そんなアドベントカレンダーですが、企業毎のアドベントカレンダーも存在しています。 そんな中、いろんな企業がやっていたので自分もやってみたいと思い、いま勤めている会社のアドベントカレンダーを作り、AutoScalingについて記事を投稿させて頂きました。 なかなか無い機会なので、やろうと思った理由とAutoScalingを書いた理由をかる〜くメモっておきます。

続きを読む

沖縄でAirbnbを使って暮らしながら泊まってきた

airbnb ライフ

時間の流れは早いもので、あっという間に11月も後半。
東京は秋服の人が増え、肌寒くなってきました。
少し前の話になりますが、10月の三連休に会社の同僚4人と沖縄に旅行に行ってきました。

泊まった所はココ↓
www.airbnb.jp

その前になぜ沖縄なのか、説明しますと完全にノリです

自分のノリで会社の仲良いメンバーに声を掛けてみました。
沖縄に行った事がない人がほとんどで、どこに行こうか迷ったのですが、沖縄といえば海!なので、海が満喫出来る所でいい所は無いかなーと考えていたら、Airbnbで泊まってみたいところあったなと思い出しました。

そういう訳で、沖縄でAirbnbを使って海を満喫できる家を借りた話です。

続きを読む

iノードを学ぶ

iノード インフラ知識

Desktop

iノードとはファイルシステム上でファイルやディレクトリを管理するためのデータです。

iノード番号というものがあり、これは限りがあります。この限界を超えてしまうとファイルやディレクトリが作成できなくなってしまうのです。 このiノード番号はパーティションサイズにより限界値が決まります。

iノードで管理されるもの

iノード番号、UID(ユーザID)、GID(グループID)、パーミッション、ファイルサイズ、ファイル作成時間、更新日時、実際のデータの位置(ディスク上の物理的な場所)、そのファイル自身への参照数を管理しています。

確かめてみる

vagrantでubuntu14.04を立ち上げてみて、iノードを見てます。


# df -i
Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sda1      2621440 69573 2551867    3% /
none             62719     2   62717    1% /sys/fs/cgroup
udev             61480   401   61079    1% /dev
tmpfs            62719   328   62391    1% /run
none             62719     1   62718    1% /run/lock
none             62719     1   62718    1% /run/shm
none             62719     2   62717    1% /run/user
vagrant           1000     0    1000    0% /vagrant
vagrant_data      1000     0    1000    0% /vagrant_data

各フィールドの意味

フィールド名意味
Inodesそのデバイスで作成できる、inodeの限界値
IUsed現在のinode 使用量
IFree残り作成できるinode数
IUse%inodeの使用率(%)

/dev/sda1はiノードが2621440あって、現在69573使っていて残りは2551867みたいですね。 残り2551867はファイルやディレクトリが作成できます。

次にiノード番号を見てみます。 hoge.txtを作りました。


# ls -li
total 0
284 -rw-r--r-- 1 root root 0 Sep 25 04:33 hoge.txt

一番左がiノード番号ですので、284これがhoge.txtのiノード番号です。

そういえば、ファイルを作る前は/dev/sda1はiノードの残りが、2551867でした。 hoge.txtを作った後はどうなったか見てみます。


# df -i
Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sda1      2621440 69574 2551866    3% /

ちゃんと1減ってますね。

iノードを枯渇させてみる

iノードが少ないパーティションを用意してみました。


Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sda5         2560    11    2549    1% /mnt

iノードの空きが2549あるので、2549個ファイルを作ってみます。


touch {1..2549}.txt

Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sda5         2560  2560       0  100% /mnt

見事iノードが100%になりました。この状態でファイルを作ろうとすると。。。


touch hoge.txt
touch: cannot touch ‘hoge.txt’: No space left on device

空き容量が無いとエラーになりました。実際に容量をみてみると余裕はあります。


df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5       8.7M  147K  7.9M   2% /mnt

まとめ

  • iノードがiノード番号、UID(ユーザID)、GID(グループID)、パーミッション、ファイルサイズ、ファイル作成時間、更新日時、実際のデータの位置(ディスク上の物理的な場所)、そのファイル自身への参照数を管理している
  • パーティションサイズによってiノードの限界値が決まる
  • ディスク容量だけ注視するのではなく、iノードの数にも気をつける
  • 大量にファイルが作成される場合は、iノードの数に気をつける

参考サイト

iノード(inode)とは iノードってなに? iノードの理解を深める

キィニョンの生クリーム食パンを買うには販売15分前に並べ

キィニョン ヒカリエ ライフ 生クリーム食パン

生クリーム食パン

生クリーム食パンってめちゃくちゃ柔らかい

ついに今日、ヒカリエにある「ラ・ブランジュリ キィニョン」で、生クリーム食パンを手に入れました。

実はこのシルバーウィーク中に買いに行ってみようと奥さんと話していて、昨日(9/22日)にヒカリエに行ってきました。

着いたのが13時30分ごろだったのですが、なんと売り切れ...この日は販売開始から40分で完売したそうです。(さらにその前日は20分で完売。恐ろしい)

ということがあったので、今日(9/23日)にリベンジしてきました。

販売開始の15分前に並べ

ヒカリエにあるキィニョンでは、生クリーム食パンを12時より販売開始しています。 今日は昨日の反省を活かし、1時間前の11時にヒカリエに到着。 さっそくお店に向かいましたが、さすがに誰も並んでおらず。そのままヒカリエをブラブラ。 お店の雰囲気

10分ほど時間を潰して、またお店の様子を見に行きましたが、まだ誰も並んでない。

お店の様子が見える位置で11時45分まで待機していましたが、普通に買い物する人はいるものの誰も並ぶ様子はありませんでした。

11時45分にお店に向かい、店員さんに「並んでいいですか?」と聞くと「自然とお客さんが集まって列になるので、並ぶということは特にしなくても大丈夫かも?」との事。

なので、お店の商品を見て時間を潰す事に。

11時50分くらいから生クリーム食パンの試食の準備が始まり、その時にチラホラ人が集まってきました。といっても3人程度。

生クリーム食パン狙いの人もいれば、たまたま買いに来たときに試食が始まるから並んでみようという人も。

自分はそのまま試食台の列に並んでました。するとその列が気になってあれよあれよと20人くらいの列になりました。

キィニョンの生クリーム食パンは一人2斤までなので、列に並んでいると店員さんに必要な数を聞かれました。 結構皆さん気になるようでとりあえず2斤いっておくかという感じで2斤頼んでいる人が多かったです。(自分は1斤)

丁度12時になったタイミングで店員さんが、列に並んでいる人に生クリーム食パンを配り始め、そのままレジに直行。

食べ比べも必要かと思い、キィニョンの食パンも半斤購入。12時5分頃にお店を出ました。

といった感じで、販売開始の15分前(11時45分)にはお店に入れば間違いなく購入できるかと思います。列が気になったお客さんも集まるので、まだ誰もいないから大丈夫と思っていると気づいた時にはすごい列になっているかもしれません。

生クリーム食パンは口の中で消える

なにもつけなくてもおいしいとの事で、まずは生で食べてみました。 とてもふわふわ。ほんのり生クリームの風味がして、いくらでも食べれる感じ。なにもつけなくても十分なおいしさ。

生クリーム食パンを焼いてみた

わかりにくいですが、焼いてみました。焼くと口にいれて噛んだ瞬間にジュワっとしてあっという間に消えてしまいました。まさに大トロのような感じ。

こんなん朝に食べたら最高ですね。こちらもなにもつけなくてもめちゃくちゃ美味しい。

普通の食パンと大きさを比べた

後ろがキィニョンの食パン。若干生クリーム食パンの方が小さい。あと少し黄色感じ。

キィニョンの食パンと食べ比べた感想は、圧倒的な柔らかさと生クリームの風味。 キィニョンの食パンと比べると厚みは生クリーム食パンの方が厚いので、噛んだときの食感のやわらかさは圧倒的。 キィニョンの食パンも十分美味しいのですが、生クリーム食パンには勝てない。自分の人生の中で最強の食パン。

是非ヒカリエに立ち寄った際は一度覗いてみてください。口の中で消える食パンは本当に美味しいです。