miyasakura’s diary

日記です。

読んだ:「スタンフォード式 最高の睡眠」

スタンフォード式 最高の睡眠

スタンフォード式 最高の睡眠

内容は薄い、というか先端研究をしててもこういう本で紹介できる程度の内容は多くないので冗長な記述で無理矢理一冊にしたという印象。

しかしもちろんスタンフォードでの研究者の方の本なので読んで損はない一冊でした。

基本的には深部体温と皮膚温度の関係で眠くなり最初の90分で睡眠の質は決まる、ということ。

コーヒーは飲んじゃだめと言われるかと思ったら普通に夜じゃなければ大丈夫そうで安心したのと、やはり睡眠の深さを測るアプリは研究者的には信頼度は低いなぁというのが印象的だった。

風呂に入る時間などすぐに実践できそうな内容はあったので実行していきたい。

AWS認定(アソシエイト)試験 合格しました

先月末にデベロッパー試験に合格したので、その勢いでソリューションアーキテクトとSysOpsアドミニストレータを受けてきました。

aws.amazon.com

2週間ほど前から試験日を予約していたので、急に入った仕事を1日断ることになってしまったこの試験。x万円の収入分と試験2つの費用が3万円で実質的にかなりの出費です。

今回もほぼ勉強せずでしたが、一応いくつかのホワイトペーパーに軽く目を通しました。

AWSのホワイトペーパーは初めて読んだのですが、かなり勉強になる内容が多いので試験関係なくちゃんと読んでおきたい資料だなと思いました。

ただ、分量が多いので一つの資料の前半くらいしか読みきれず試験に挑むことになったわけなのですが、一応試験は合格。

結果的にはどの試験もスコアが80%超えていたので自分の知識に一安心です。

SysOpsは始まったばっかりなのか合格証の番号がJP-897と若めで、ソリューションアーキテクトは JP-6614 なのでかなりの人が取ってるみたいです。

次はプロフェッショナルを目指して頑張ります。

DockerでRails+Wheneverによるcron実行

cronは cron -f で動かせるが、環境変数が引き継がれないので期待した動作をしてくれない。少しやり方に悩んだので解決方法をメモ。

Wheneverはenvを記述することでcrontab内に環境変数を定義してくれるのでそれを利用した。結果としては下記のようになった。

env :BUNDLE_PATH, ENV['BUNDLE_PATH']
env :BUNDLE_APP_CONFIG, ENV['BUNDLE_APP_CONFIG']
env :HOGE, ENV['HOGE']
# 他にも外部サービスの API_KEY とか色々

every 2.minutes do
  rake 'something:do'
end
#!/bin/bash

bundle exec whenever --update-crontab

LOG_FILE=$(dirname $0)/../log/production.log

touch ${LOG_FILE}
cron && tail -f ${LOG_FILE}

Dockerfileは通常通り作成し、cronを実行するコンテナとして動かすときだけ明示的にコマンドを指定する。

docker run -d <image> docker/cron.sh

以上でコンテナ実行時の環境変数をcronに渡すことができる。実行ログについてはDockerなので標準出力に出すようにした。Rails側で標準出力してもcronがそれを出力してくれるわけではないので、ファイルに出力したものを明示的にtail -fしている。

インフラエンジニアの教科書を読んだ

 何となく気になっていた下記の2冊を読みました。

 

インフラエンジニアの教科書

インフラエンジニアの教科書

 
インフラエンジニアの教科書2 スキルアップに効く技術と知識

インフラエンジニアの教科書2 スキルアップに効く技術と知識

 

広い範囲をさらっている感じで個人的には新しい知識は多くはなかったのですが、これくらいの知識は知っておかないとというのがしっかりまとまっていた印象です。

 

1冊目は物理の話やベンダーへの発注の仕方とかまで書いてあって、今必要な知識ではないですが流し読みながら面白く読めました。

 

2の方はOSやミドルウェアをカバーしていて、インフラの知識の範囲としては2冊で一通りという感じでしょうか。

 

こういった知識がこのクラウド全盛の時代にどこまで必要かということですが、例えばAWSのEBSがいわゆるSANだよね、とイメージできるだけで性能や構成の制限が直感的にイメージできたりするわけです。本格的に性能を引き出そうとしたらデータセンター内の物理構成まで意識して初めてできるのかなと思ってます。

 

そういう意味ではクラウドの時代でマシンを立てたりをアプリ側がやるようになってるので、アプリ屋さんもある程度理解していないといけないと思ってます。

 

技術が進んで抽象化が進んでも結局学ぶことは増えていくこの業界はなかなか大変ですよねぇ。

 

AWS認定 デベロッパー - アソシエイト試験を受けてきた

火曜日に思いついて予約して、本日受けてきました。

勉強は特にしていないのですが、範囲に書いてあった中でSWFだけは使ったことがなかったので一応30分くらいでチュートリアルをやりました。

結果は正答率87%で無事合格。

意外と難しかったですが、普段から出題範囲のサービスを使っていれば落ちることはないレベルかなと。

主な対象サービスはEC2, S3, DynamoDB, SQS, SNS, EB, CloudFormatin, SWFなどで、基本的なWebの知識がないと解けない問題もそれなりにありました。

せっかくなので残りのアソシエイトレベルの試験もさくっと取ってしまおうかなと思ってます。サンプル問題を見る限りではソリューションアーキテクトは余裕で、SysOpsはちょっと勉強が必要そう。

読んだ:「7つの習慣―成功には原則があった!」

今更な自己啓発本(ビジネス書?)ですが、読んでみました。というかFebeのAudio Bookで聴きました。

www.febe.jp

古い訳の方ですがまぁ良いかなと。

当たり前のことといえば当たり前のことだし、これまで実践してきたこともあったりはするわけですが、30歳というこの時点で読んで良かった気がします。誰にでもおすすめできる本。

読んだ:「マイクロサービスアーキテクチャ」

www.oreilly.co.jp

やや流し読みですが。

全体的にマイクロサービスをやる上で気をつけるべきところを紹介してはくれているんですが、実際にやって大変そうだなというところは、大変だから頑張ってね、くらいしか書かれていないので実践的とまではいかない感じ。

考えなきゃいけない部分が基礎的なこと含めて色々と書かれているので、マイクロサービスやるにあたっては読んでおいて良いはず。

以下はメモ。自分が気になったところだけメモしつつ読もうと思ったけど途中で面倒になったので適当です。

  • サービスを分離する大きさ
    • 2週間で作り直せる大きさ
    • あるいは感覚的に十分に小さいと感じる大きさ
  • サービス内のことはそれほど気にしなくて良い。サービス間は心配する
    • サービス間の通信がRESTだったりJava RMIだったりした場合の大変さ
  • 戦略的目標←アーキテクチャ上の原則←設計とデリバリのプラクティス
  • 非同期イベントベース連携
    • マイクロサービスがイベントを発行する方法と、コンシューマがそのイベントを発生したことを検出する方法について
    • RabbitMQなどのメッセージブローカー
  • 4章 結合
    • 1つのマイクロサービス内ではDRYを破らないが、すべてのサービスにわたるDRYの違反には寛大に対処する
      • サービス間の結合が多すぎることに寄る外はコードの重複が引き起こす問題よりもはるかに悪くなる
    • クライアントライブラリ
    • ついサーバにあるべきロジックがクライアントに紛れ込んでしまう
    • AWSのモデルが好き
      • コミュニティや開発者以外のAWSメンバーが開発することで落とし穴を回避
      • クライアントがアップグレードを行うタイミングを管理できる
    • バージョニング
  • 5章 モノリスの分離