筋肉アドベントカレンダー2017の18日目の記事を書かせてもらいます。
いきなり半年トレニーング続けた感想を言ってしまうと 「めっちゃ楽しい！」「重い物を持ち上げたい！」 です。（現在ベンチプレス 90kg 1rep、スクワット、デットリフトはまだ計測したことがありません）
3ヶ月くらい続けた頃に「体つきが変わった」「ガタイが良くなった」と言われるようになってモチベーション高くなりました。
今回筋肉アドベントカレンダーでは、筋トレを始めたきっかけやトレーニングの始め方などを半年続けた目線で書かせてもらいます。
筋トレ半年の初心者の話で恐縮ですが、誰かの筋トレを始めるきっかけになってくれると幸いです！（この投稿は18日の昼くらいになってると思います…すみませんすみません）
続きを読む
NoSQLデータベースであるDynamoDBに今更ながら入門してみようと思います。
こちらの記事を参考に手を動かしながら、感覚をつかもうと思います。
AWS再入門 Amazon DynamoDB 編 ｜ Developers.IO
また、DynamoDBにはハッシュキー、レンジキーといった概念があるので、それらを理解する為にこちらを参考にさせて頂きます。
Amazon DynamoDBはマネージドなNoSQLデータベースです。RDBMSとは違い、リレーションやトランザクションといった概念がありません。しかし、キャパシティが自動でスケールするなど管理する項目が少ないのが特徴です。また、RDSとは以下の点が違います。
RDS DynamoDB 一貫性 強力 結果整合なので基本的に弱い（強整合性指定も可能） 原子性 ある ない（同じアイテム内の更新であれば可能） 検索条件 SQLのWHERE句で自由自在 事前指定のキーまたはインデックスのみ 可用性 メンテナンスウィンドウあり 基本的に常に利用可 拡張性 スケールアップのみで天井が低い シャーディングによるスケールアウトが可能
結果整合性はS3と同じですね。データ更新直後はデータが取得できなかったり、古いものが取得される可能性があります。
続きを読む
AWS最古のサービスSQSを今回は触ってみます。
Amazon Simple Queue Service（Amazon SQS）には、コンピュータ間で送受信されるメッセージを格納するための、信頼性の高いスケーラブルなホストされたキューが用意されています。Amazon SQS を使用することによって、さまざまなタスクを実行するアプリケーションの分散コンポーネント間で、データを簡単に移動させることができます。
キューイングサービスですね。どういう用途に使うかというと、例えば処理を切り離したい時に使う事が出来ます。
DBのデータ更新系の処理だとして、リクエストを受け付けて、その後DBの更新を行うとし、このDB更新に時間が掛かるとします。更新が完了するまでの間レスポンスが帰ってこない状態になってしまうと思います。これを受付と更新とで切り分ける時にキューイングの出番です。
受付処理の時にキューイングに更新依頼きたよーとキューにメッセージを入れます。キューにメッセージを入れたら、レスポンスを返却します。その後、ワーカーがキューのメッセージの有無を確認し、メッセージがあればDBを更新します。
キューイングを用いると処理を切り話す事が出来ます。
続きを読むキューは、データの生成と保存を行うコンポーネントと、データを受信して処理を行うコンポーネントの間のバッファーとして機能します。つまりキューは、消費者（Consumer）の処理スピードよりも生産者（Producer）が早く作業を生成したり、生産者と消費者がネットワークに断続的に接続されている場合などに発生する問題を解決します。
今回はAWSのサービスの一つであるElastic Beanstalkを触ってみたいと思います。
ELB,EC2,AutoScalingがセットになったPaaSです。アプリエンジニアは作成したアプリケーションをElastic Beanstalkにデプロイするだけでサービスを展開出来るので、アプリ開発に集中する事ができます。 現在（2015年12月時点）サポートしているのはJava、.NET、PHP、Node.js、Python、Ruby、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.com ※投稿したアドベントカレンダー一日目の記事
Qiitaというエンジニア向けの情報サイトには毎年恒例のアドベントカレンダーというものがあります。これは12/1 ~ 25日まで、あるテーマに沿った記事を毎日交代で書いていくものです。同じ人が複数書いても問題ありません。テーマはそれぞれで、言語であったり、AWSであったりと多岐にわたります。
そんなアドベントカレンダーですが、企業毎のアドベントカレンダーも存在しています。
そんな中、いろんな企業がやっていたので自分もやってみたいと思い、いま勤めている会社のアドベントカレンダーを作り、AutoScalingについて記事を投稿させて頂きました。
なかなか無い機会なので、やろうと思った理由とAutoScalingを書いた理由をかる〜くメモっておきます。
時間の流れは早いもので、あっという間に11月も後半。
東京は秋服の人が増え、肌寒くなってきました。
少し前の話になりますが、10月の三連休に会社の同僚4人と沖縄に旅行に行ってきました。
泊まった所はココ↓
www.airbnb.jp
その前になぜ沖縄なのか、説明しますと完全にノリです
自分のノリで会社の仲良いメンバーに声を掛けてみました。
沖縄に行った事がない人がほとんどで、どこに行こうか迷ったのですが、沖縄といえば海！なので、海が満喫出来る所でいい所は無いかなーと考えていたら、Airbnbで泊まってみたいところあったなと思い出しました。
そういう訳で、沖縄でAirbnbを使って海を満喫できる家を借りた話です。
続きを読む
iノードとはファイルシステム上でファイルやディレクトリを管理するためのデータです。
iノード番号というものがあり、これは限りがあります。この限界を超えてしまうとファイルやディレクトリが作成できなくなってしまうのです。 このiノード番号はパーティションサイズにより限界値が決まります。
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ノードが少ないパーティションを用意してみました。
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
