nagu log

忘れないために

ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得のおぼえがき

f:id:csnagu:20191123173559p:plain

はじめに

山浦 清透(@ kiyotoyamaura)さんがUdemyで公開している「AWS:ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得」を観てみたおぼえがき。
AWSのLambdaやS3は使ったことがあったが、AWSのサービスを組み合わせてインフラを作ったことがなかったため、勉強がてらやってみた。

Udemyのコース: https://www.udemy.com/share/101YbyCUYed1xXR3Q=/

コースの内容

コースは基礎編と発展編の2セクションに大別できる。

基礎編

IAM / CloudWatch / CloudTrail / VPC / EC2 / Elastic IP / Route53 / RDS / WordPress についての説明とハンズオンがある。
主にやることは以下の通り。

GCPやAzureなど使ったことがなくAWSほんとになんもわからんという人向けに感じた。キイタコトアル人は2倍速で再生すると丁度いい。 インフラを作ろうということで、コースの途中でTCP/IPやHTTPとはみたいな話があるが、あまり深く掘り下げないので別に参照するものをおいていたほうが良さそう。下記参考書籍を読んでおけば特に詰まることなく進められた。

参考書籍:
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
マスタリングTCP/IP―入門編―(第6版)

発展編

S3 / CloudFront / ELB / RDS / AMI / CloudWatch / IAM についての説明とハンズオンがある。 主にやることは以下の通り。

  • WPの画像保存先をS3に変更する
  • S3の画像をCloudFrontでキャッシュする
  • 独自ドメインで画像を取得できるように代替ドメインを設定する
  • EC2インスタンスを増やしてELBでWebサーバを冗長化する
  • RDSを冗長化する
  • CloudWatchでメトリクスの監視設定をする。アラートを飛ばす
  • IAMでポリシーやユーザグループ、ロールなどを作成してアクセス管理を学ぶ

インフラ設計における重要な観点

  • 可用性 ... サービスを継続的に利用できること
  • 性能・拡張性 ... 性能は十分であること、将来的にシステムを拡張できること
  • 運用保守性 ... 運用保守がしやすいこと
  • セキュリティ ... 情報が守れらていること
  • 移行性 ... 他のシステムに移行しやすいこと

メディアの保存先をWebサーバーから分離するメリット

  • Webサーバのストレージをメディアで圧迫しない
  • HTMLへのアクセスと、メディアへのアクセスを分けて負荷分散する
  • Webサーバの台数を増やしやすくなる
  • コンテンツ配信サービス(CloudFront)から配信することで、高速化できる

IAMについて

  • ポリシー ... EC2とS3といったリソース対するアクセス権限の定義
  • ユーザー ... 君や私。ポリシーが割り当てられる
  • グループ ... 複数ユーザへのポリシー割り当てをまとめて行える
  • ロール ... EC2やLambda等のAWSリソースに対して設定するアクセス権限

ポリシーは基本的にユーザやグループへ割り当てるために利用する。一方で、ロールはAWSのリソース(EC2、Lambda等)に対してアクセス権限を付与する際に利用する。アクセス権限が必要な操作を行うときに、一時的にアクセスキーとシークレットキーを発行して利用する。バックではAWSのKMS(Key Management Service)を利用しているらしい。 ポリシーとロールの違いがチョット怪しい。(~_~)

WebサーバとDBサーバを分けたら何が嬉しいのかと言うのは [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) に詳細に書いていた気がする。

感想

AWSとかいうの正直サービスが多すぎて何から手を付けて良いのかわからんという状態だったが、目的を持って(今回の場合はWordPressを立ててみよう)体系的に学べるのは非常に良い。こういうのを積み重ねていくとユースケースが自然と刷り込まれていって、課題に対する反射神経が上がるのかなと思った。
Route53でドメイン利用できるようにしたり、CloudFrontを利用したら本当に早くなってるじゃんって確認するところは楽しかった。WebサーバとDBサーバを分けるところのように、何故するのかが説明されているのは良き。

また、初Udemyということで書籍との感覚の違いについてもメモしておく。LTとかスライド的なものを見るのが好きな人はもちろん、初めてで何もわからんからハンズオン的に手を動かして学びたい場合は、書籍よりもUdemyやpluralsighのような動画コンテンツで学ぶほうが圧倒的に良いと思った。目の前で操作がされており、操作を見逃したとしても5秒前とかに戻って確認することが容易なためとにかくとっつきやすい。
一方で既に知っている内容をスキップするときにスキップしすぎたりということが発生するので、ここらへんは書籍のほうがペースをつかみやすいなと思った。

入門 監視のおぼえがき

f:id:csnagu:20191007224613j:plain
入門 監視

はじめに

Mike Julian 著、松浦 隼人 訳な『入門 監視 ――モダンなモニタリングのためのデザインパターン』を読んだおぼえがき。

そもそも『入門 監視』を購入するに至った経緯についてだが、2019年の下期からログのプラットフォームを運用するチームに配属となった。この時点では「ログや監視まるでわからん」といった感想しか持っていなかったため、流石に「これはいかん」となり、少し前に自分のTLで話題になっていた『入門 監視』を読み始めた。

入門 監視を読んでみて

『入門 監視』は、監視ツールに依存しない監視の基本だったり、なぜ監視するのかといった、基本的な部分を丁寧に解説してくれている。
監視のアンチパターンからデザインパターン、ビジネスKPI・フロントエンド・アプリ・サーバ・ネットワークなどコンテンツがたくさんあるが、各章では「何を、なんのために、どのように監視するのか」がまとめられていて非常に良い内容だと思う。

そのため、自分のような「どんな背景があってXXXを監視しているのか」「そもそもなぜ監視するのか」といった基本的な部分を補うのに最適であったように思う。

また、OSSの監視ツールがある中で、商用のSaaSを利用する理由やメリットなどは納得感があったし、業界や企業側の世界観がいまいちつかめていなかった自分としては学びが多かったように思う。ロギングや監視といった主軸のコンテンツからは若干逸れるが、OSSを採用するか商用SaaSを採用するかは、安定稼働までのコストや機会損失、セキュリティ面などを総合的に判断しなければいけなく、必ずしもOSSバンザイな姿勢ではいけないことを学んだ。

その他にも、運用に関する手順書を作成するのは作業途中に人間の判断が必要な場合だけにして、ログやメトリクスを監視することで積極的に自動化してしまおうといった話題は面白かった。

最後の章には総まとめの例題がある。フィクションのコンサルタントを例に、本書を通して学ぶ「何を、なんのために、どのように監視するのか」を確認させてくれる内容となっていた。全体を思い返すのに非常にいい構成だったと思う。

もう少し実務を積んでから読み返すことで新たな気付きがありそうな気がとてもしている。定期的に読み直していきたい。

www.oreilly.co.jp

テスト駆動開発のおぼえがき

はじめに

Kent Beck 著、和田卓人 訳な『テスト駆動開発』を読んだ覚書。
タイミングが良いことに、仕事先のお試しプロジェクトをテスト駆動開発で進める機会があったので、これについても感想を綴ります。

f:id:csnagu:20190901182625p:plain
テスト駆動開発

テスト駆動開発とは

  • Red→Green→Refactorを小さいステップで高速で回す
    • Red ... 書いたテストを実行してレッドバーの表示を確認する
    • Green ... とりあえずテストが通る形で実装する
    • Refactor ... 引数で取得できたり、柔軟に変更できる箇所をリファクタリングする
  • ブラックボックステストを仮定して、投入するものと期待する結果を考える
    • やりたいことを明確に表現できる
  • 実装ではなくテストから先に考える
    • 開発をシンプルにすすめることができる
  • テストを書く理由

個人的に大事だなと思ったのはこんなところ。

特に、やりたいことを最初にテストで表現する、という部分に惹かれた。
実装の前と後に書かれるテストは中身が変わるのかなと思った。というのも、実装後に書くテストはホワイトボックステストになりがち(だと思う)だが、、実装前にテストを書くことでブラックボックステストになりやすいと思う。
その結果、内部の仕様を変更したとしてもテストがコケにくくなり、テストの保守に労力をあまり割かなくて良くなるのかなと感じた。

あとはRed, Green, Refactorを小さいステップで回すことで目標に向かって柔軟に実装できるという箇所が読んでて「素晴らしい…」ってなるポイントだった。

テスト駆動を実施してみて

ここまでは本で読んで「こういうことかな〜」という話。
ここから先は1ヶ月に満たない短い期間でテスト駆動開発を実際に導入してみてのオハナシになります。

実際に導入してみるとなかなか理想通りにはできなかった。
うまくいかなかった事例としては以下の通り。

  • テストで担保するべき最低ラインで意見が割れる
    • そもそも個々人でテスト力がバラバラなので当然
  • Red, Green, RefactorのRedは意識しないとすっ飛ばす
  • 「あれ、これはスモールステップではない...?」
  • テスト駆動のハズが、「こんな感じでは?」と話しているうちに実装が終わってしまう
  • テストがホワイトボックステストっぽくなる

そもそも本読んだだけで、1ヶ月の間で初テスト駆動開発というのは無理があった。
とは言うものの、やってみるとテストのありがたみの片鱗を知ることができたのでいい経験になりました。

AWSボタンを使ってGitHub Contributions風の草を生やしてみた

はじめに

GitHubに草を生やしていくとやっている感があっていい。
自分のGitHubページにアクセスして進捗草が生い茂っていたら「今日も頑張るぞい」ってなるに違いない。
何かをやったということが視覚的にわかるので、自己肯定感もアゲアゲなはず。

こんなふうに、毎日たくさんの進捗草に囲まれていたら、きっと人生楽しくなっちゃいますね。

というわけで、AWS進捗ボタンを利用してGitHub風の芝生を作ってみました。

実際に生えてくるのは青い草です。
青臭いという自戒と、草青むという希望を込めて

動機

  • APIサーバという概念を仕入れたからなんか作ってみたい
  • そういえばAWS進捗ボタン使ってない…そや、再利用しよう
  • GitHubの芝生が枯れてる…人生の進捗はコードだけじゃないはず
  • AWS進捗ボタンはPythonでデータ処理しているからAPIサーバはflaskで作る
  • heroku使ってみよ

こんな動機で出来上がったアーキテクチャ図(作ってみたかっただけ)

f:id:csnagu:20190629150942p:plain
なんちゃってアーキテクチャ図 icon by https://icons8.jp

  1. GitHub Pagesで運用している https://naguu.info へアクセス
  2. herokuで動かしているflask製のapiサーバへGETリクエストを飛ばす
  3. apiサーバが S3 から記録データを取得
  4. apiサーバ内でデータ処理してjson形式でreturn
  5. jsでヒートマップカレンダーとして出力

どんなもの

実際に使っているのがこんな感じ。

f:id:csnagu:20190629145716p:plain
青い芝のdemo

ヒートマップカレンダーはDKirwan氏のcalendar-heatmapをほぼそのまま利用しています。
便利。

github.com

なんちゃってapiサーバの実装はgistを参照。

現状の課題や未来の自分へのTodo

  • naguu.info/ へのリクエストごとにAWS S3からcsvファイルをダウンロードしているから表示が遅い
  • flask製のAPIサーバではGETのたびにデータに前処理を施しているから遅い
  • AWS進捗ボタン側のデータを使ってcontributions毎の時間をグラフで出したら面白いかも
  • ヒートマップカレンダーの実装が人に頼り切り

良い感じの実装方法などあればコメント等で教えてください!

TodoistとTrello、2つのタスク管理ツールの使い分け

はじめに

個人的なタスク管理ツールは主にTodoistとTrelloを使っている。
「シンプルでタスク完了とともにリストからタスクが消えるTodoist」

「タスクをtodo/doing/doneと分けられるTrello」
とでそれぞれ使う方針がだいたい固まってきたため、現在の使い分けをできるだけ具体的にメモしておく。
他にもこんなツールあるぜ!こんな使い方いいぜ!っていうのは教えてほしい。

Trelloではタスクのことをカードって呼んでるので、ここではタスクに統一する。

Todoist

良かったところ

  • UIがシンプルでスッキリして見やすい
  • PC・スマホタブレットどれから閲覧してもほぼ同じように操作できる
  • こなしたタスクはリストから消えていく(実際にはログに残っている)
  • 毎日/明日/3日毎 などで同じ内容のタスクを勝手に作ってくれる機能がある
  • Amazon Echoと連携できる

イマイチなところ

  • タスクに日付を指定しないとインボックスやプロジェクトの中で埋まる恐れがある
  • コメント機能がプレミアムユーザのみ
    • しかもそんな使い勝手がよくない

こんな理由からTodoistは「ぱっと見て理解できる」「時間がかからない軽いもの」「ある日付のみ実行する」タスクを登録するようにしている。
例えば週末の掃除は「毎週日曜日 シンクの掃除」として登録する。すると掃除のリストが出来上がる。実行した掃除項目から手軽に消せるため、残りの掃除箇所がどこかも把握しやすい。
他には「5/23 サイクリング」といった、ある日付のみ実行するものを登録する。
また、Amazon Echoと連携できるので思いつきのメモをとりあえず残しておけるのも◎。

逆に相性が悪いな〜と感じたのは、課題やレポート提出のような「ある日付までに継続的に取り組む必要があるもの」。
それとタスクを分解して小タスクに分けていくのも個人的には使いにくいな〜と感じている。
複雑であったり、重ためなタスクはTrelloのほうが管理しやすい。

Trello

良かったところ

  • リストやボードを使い分けれるので自由度が高い
  • doneリストが増えていくと嬉しい
  • タスクごとに説明やコメントなどの詳細を記述できる
  • Hello Epics(プラグインのようなもの、有料)がタスクの親子関係や全体の進捗を明確にする

イマイチなところ

  • Chromeエクステンションがないと使い勝手が悪い
  • タスクの登録と完了が若干煩雑
  • タスクをソートできない

Trelloは「複雑な内容」「継続的に取り組む」タスクを登録するようにしている。
複雑な内容のタスクはより細かい作業に分割するのが定石である。Hello Epicsを使おう。
次に、継続的に取り組むタスクとして最近はじめた積読の消化がある。Hello Epicsを使おう。
画像で伝われTrello(Hello Epics)の力。

f:id:csnagu:20190511211005p:plain
trello + hello epics

Trelloの各タスクには説明欄とコメント欄があるため、本を読み始めた動機やモチベ、読書メモ等を書き込むのもいいだろう。
長い間doingリストに所属するタスクは理由をメモして、更に小タスクへ分割することもできる。

Trelloは以下記事にあるChromeエクステンション入れると使い勝手が異次元になる。
そのかわりスマホタブレットから閲覧したときは残念な気持ちになる。

qiita.com