ニクニクドットミー

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

スポンサーリンク

筋トレを始めて半年経ったので振り返ります

f:id:maaaato:20170212183612j:plain

adventar.org

筋肉アドベントカレンダー2017の18日目の記事を書かせてもらいます。

いきなり半年トレニーング続けた感想を言ってしまうと 「めっちゃ楽しい!」「重い物を持ち上げたい!」 です。(現在ベンチプレス 90kg 1rep、スクワット、デットリフトはまだ計測したことがありません)

3ヶ月くらい続けた頃に「体つきが変わった」「ガタイが良くなった」と言われるようになってモチベーション高くなりました。

今回筋肉アドベントカレンダーでは、筋トレを始めたきっかけやトレーニングの始め方などを半年続けた目線で書かせてもらいます。

筋トレ半年の初心者の話で恐縮ですが、誰かの筋トレを始めるきっかけになってくれると幸いです!(この投稿は18日の昼くらいになってると思います…すみませんすみません)

続きを読む

【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をただただ触ってみただけの話

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をただただ触ってみただけの話

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の話を投稿しました

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

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

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

続きを読む

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

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

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

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

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

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

続きを読む

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ノードの理解を深める