AWS

この１年半はインフラエンジニアっぽい仕事から離れて、LookML 開発者として仕事をしています。自分としてはジョブチェンジで、モチベーションはめっちゃ高いです。うぉー！🔥 LookML 開発に出来るだけ専念できるように配慮して頂いたり、自分でもそう心がけていますが、それでも DNS レコードの登録依頼や、その他諸々の相談がちょいちょいあります。 DNS レコードは Route 53 で管理しています。言われるがままに登録していけば悩みはないのですが、何のために登録するのか？や、登録されているこのレコードは何だ？とか考え始めると地味に悩ましいものがあります。 今の仕事では Terraform は使っていないし、このためだけに Terraform を導入するのはオーバー過ぎます。 Terraform を導入したらアップデートし続けない選択肢はありませんが、変なエラーでハマって何時間も浪費することがあります。今の仕事の性質上、それは絶対に避けたいので、Terraform 以外で Route 53 の DNS レコードを管理する方法を調べてみました。 SAM で管理できるか？ つまり CloudFormation 管理下に置くか？ということです。 Terraform ではツールのアップデートに追随する必要がありますが、SAM なら serverless-application-model のバージョンに追随すれば良いだけです。最新は 2016/10/31 なので、あまり考えなくて良さそうです。 結論としては、止めたほうが良いと思いました。良くも悪くも CloudFormation 管理下に置かれるので、Route 53 Console 上で気軽に変更するとコードと乖離してしまいます。そのため常に SAM で変更する必要があります。もっとカジュアルに管理したいのです。 ちなみにこんな template.yaml で DNS レコードを作れます。ただ更新がうまく出来なかった。それ以上は調べてない…。 AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: Managed by AWS SAM Resources: Hoge: Type: AWS::Route53::RecordSet Properties: HostedZoneId: xxxxxxxxxxxxxx Name: hoge.masutaka.net. Type: TXT TTL: 300 ResourceRecords: - '"abcdefgxyz"' AWS CLI で管理できるか？ そもそもエネルギーを注ぐところではないので、新しいツールは増やしたくないところ。そういう意味では AWS CLI でどこまで出来るかは興味がありました。...

【ダウンロード版】AWSの薄い本　IAMのマニアックな話 - 佐々木拓郎のオンライン本屋 - BOOTH 少し前に Twitter で流れてきて買ったのかな。最近 AWS 等の権限まわりに課題を感じることが増えてきたので読んだ。デザインパターンやセキュリティ、運用方法など、参考になることが多くて、読んで良かった。 開発者用の IAM User の権限はやっぱり難しいみたいで、ああなるほどと思ってみたり。 仕事では開発用の共通 IAM User development を作って、.envrc 経由で使っているんだけど、さすがにドンピシャの解はなかった。 本当は開発者ごとの開発用 IAM User（例: masutaka-devel）を作って、共通 IAM User は使わないほうが良いのだろうなあ。開発者ごとの通常 IAM User（例: masutaka）は作っているんだけど。 CloudFormation によるコード管理にも触れていて、IAM Group や Role までは管理するけど、IAM User は管理しないとのこと。なぜなら IAM User は一度作ったらお終いだから。なるほど。 CloudFormation はまだ直接使ったことがないので、本書にあるようにハードルが低い IAM から始めるのは良いと思った。 IAM Policy を使った MFA の強制もやらないとな。そういえば他のチームはやっていたな。 P.S. .pdf 以外にも .epub か .mobi 形式も欲しかった。気になった箇所にマーカーやメモを付けたかった。目次からの移動も出来ないので不便。 追記(2020-03-15): Kindle 本発売されたようです。 Kindle本の販売という実績解除しました - プログラマでありたい

https://jawsdays2019.jaws-ug.jp [2017-03-12-1] [2018-03-11-1] に引き続き、3 回目の参加です。去年の 6 月に EKS が GA になり 、その後 12 月に Tokyo Region でも使えるようになった 影響で、Kubernetes のセッションが大盛況でした。その他はそれほど変わらなかったように見えました。 午前中は AI/ML 関係のセッションをなんとなく見ていました。 [AI/ML] PythonとSageMakerで始める MLチームのみで完結するAPIの構築事例 武田 研恒さん やっぱり機械学習エンジニアがサーバーの面倒見るのは無理というかもったいないよね、うんうんと聞いていました。 [AI/ML] メディアによるAI活用（時事クイズの生成と高校野球戦評記事の自動生成） 佐渡 昭彦さん 朝日新聞には、ICTRAD（アイシートラッド）と呼ばれる、情報技術本部（技術系）内にある研究開発チームがあるそう。本セッションのような研究や、セキュリティ対策をしているそう。朝日新聞はよく攻撃されるらしい。なるほど。 AI で時事クイズを作成。 Amazon Comprehend は日本語対応していないので不採用。 東大・横国大のオープンソース『専門用語（キーワード）自動抽出システム 』を使って、分かち書きと単語ベクトル化（？）をしているらしい。 朝日新聞でも単語ベクトルを公開している。→ 朝日新聞単語ベクトル EC2 1 台で足りているとのこと。 ランチタイム めちゃめちゃ混んでいたけどなんとかゲット。種類を選ぶ余裕はなかった。職場の同僚 3 人はゲットできなかったそう。1000 人超もの弁当を用意した運営の方々には頭が下がります。 [Container/k8s] GitHub Actionsを使って、ワークフローもプルリクベースで開発しよう！ 池田 尚史さん TODO: 資料が公開されたらここに貼る [2019-02-11-1] に自作の GitHub Action を GitHub Marketplace に公開したばかりなので、聞いてみました。 これはドキュメントに書いてない。GitHub Actions は HashiCorp 好きのエンジニアが作っていそう。...

ここ一年半くらい、このブログが乗っていたサーバをメンテンスしていませんでした。４月に Ubuntu 14.04 LTS が EOL になることと、サーバの面倒をみることに疲れてしまったので、このブログを CloudFront+Heroku に移しました。 さくらのVPSに引っ越したのは [2013-05-27-2] だったので、５年半くらい使っていたことになります。このブログ自体は静的コンテンツですが、nginx のログを fluentd に流したり、各種メトリクスを kibana や GrowthForecast で可視化したり、ちょっとしたアプリケーションを動かしたり、いろいろ実験や素振りをすることが出来ました。今までありがとう。 さて、引っ越し前後の環境の変化です。 引っ越し前（さくらのVPS） https://vps.sakura.ad.jp/ 仮想サーバのプラン 2G、石狩リージョン、年額 18,770 円 ドメイン さくらのドメイン、年額 1,852 円 OS Ubuntu 14.04 LTS 構成管理 knife-solo デプロイ方法 GitHub の master ブランチに push すると、CircleCI 上で capistrano が自動デプロイ ビルド方法 capistrano でのデプロイ時に chalow が CHANGELOG メモを HTML に変換 配信方法 静的な HTML ファイルを nginx が配信 引っ越し後（CloudFront + Heroku） https://aws.amazon.com/jp/cloudfront/ https://jp.heroku.com/ Dyno Type Hobby、年額 $7 x 12 = $84 ≒ 9,554 円 ドメイン AWS Route53、年額 $12 + ($0....

https://jawsdays2018.jaws-ug.jp 去年 [2017-03-12-1] に引き続き、２回目の参加です。去年はなかった機 械学習のセッションが目立ちました。IoT のセッションも増えてました。 以下、自分用のメモです。 [DeepDive] コンテナでウェイウェイ（仮） 西谷さんが基本的なお話をして、Calvin さんが大規模事例を紹介、とい う流れだった。 by 西谷圭介さん TODO: 資料が公開されたらここに貼る 西谷圭介さん／アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 シニアソリューションアーキテクト ECS と Fargate の基本的なお話。 今までの稼働実績を元に数ヶ月前に ECS と Fargate の SLA が 99.99% に引き上げられたらしい。 これか。 Amazon Compute サービスレベルアグリーメントを Amazon ECS および AWS Fargate に拡張 by Calvin French-Owen さん TODO: 資料が公開されたらここに貼る Calvin French-Owen さん／米国 segment.io社, CTO and Co-Founder​ segment.io 社の事例。そうとう規模が大きいらしい。 ちょっと前だけど TechCrunch の記事見つけた。 複数（20あまり）のアクセス分析サービスのAPIを簡単に呼び出せるSegment.io｜TechCrunch Japan CPU や Memory Utilization によって Auto Scale Out/In する設定にし...

全体を Allow したあとに、制限したいパスに対して Deny を追加すれば 可能。 例えば以下の場合。 https://s3-ap-northeast-1.amazonaws.com/masutaka-hoge/aaa/ * → インターネットに全公開 https://s3-ap-northeast-1.amazonaws.com/masutaka-hoge/bbb/ * → IP アドレス AAA.BBB.CCC.DDD からのアクセスのみ許可 このようなポリシーになる。 { "Id": "Policy1234567890", "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt0123456789", "Action": [ "s3:GetObject" ], "Effect": "Allow", "Resource": "arn:aws:s3:::masutaka-hoge/*", "Principal": "*" }, { "Sid": "Stmt9876543210", "Action": [ "s3:GetObject" ], "Effect": "Deny", "Resource": "arn:aws:s3:::masutaka-hoge/bbb/*", "Condition": { "NotIpAddress": { "aws:SourceIp": "AAA.BBB.CCC.DDD" } }, "Principal": "*" } ] } S3 の Console の Bucket の Permissions → Bucket Policy で上記ポリ...

[2017-07-05-1] のあとすぐ読み始めたので、およそ一ヶ月。長い旅であっ た…。 きっかけは [2017-03-12-1] の JAWS DAYS 2017 での吉田さんのセッショ ン。今まで Lambda, DynamoDB, Cognito のどれも、つまみ食いしかして 来なかったので「これだ！」と思い予約注文しました。 あわよくば、年始の Vue.js 以降停止していた JS をやり始められたら良 いかなと。 １章からいきなり S3 にデプロイし始めて、胸が熱くなるのを感じました。 ２章のルータ関数や３章のテンプレートなど、jQuery でもわりときれい に書けるんだなと感心しました。 ※ 「はじめに」のページ xii にはこの本で React や Angular を選択し なかった理由が書いてあります。 ただ、その後の４章から雲行きが怪しくなりました。非同期プログラミン グに慣れていないので、その function がいつ実行されるのか分からない 箇所が多々。 弊社の尖りまくったフロントエンドエンジニアに聞こうにも、 jQuery.Deferred の質問はなんとなくためらわれ…。 読み終わって、残念ながら Lambda, API Gateway, DynamoDB, Cognito を ふんわり触ったくらいしか印象が残りませんでした。期待値が大きすぎた 感があります。 私に刺さらなかった理由 理由を考えてみました。 ・JS が難しい JS というよりも jQuery を使った非同期プログラミングが、かもしれま せん。普段書かないコードなので、理解が困難でした。 ・独自フレームワーク sspa 実体はシェルスクリプト ですが。悪い意味でブラックボックスになってお り、読後に「これを使って SPA 作るぞ！」という気持ちにはなれません...

Day2 だけですが、今年も AWS Summit Tokyo に行ってきました。 [2014-07-19-1] から始まり、[2015-06-07-1] [2016-06-04-1] と、 今年で 4 回目の参加になります。 今回は過去最高の規模なのか、品川プリンスホテルの会場も増えてました。 グランドプリンスホテルからの移動時間は 10 分ほど。人によっては移動 が大変だったみたいです。暑かったですし。 私は聞きたいのがほとんど AWS Dev Day のセッションだったので、午後 は全部品川プリンスホテルに引き篭もっていました。 全てのセッションの動画や資料はこちらをどうぞ。 AWS Summit Tokyo 2017 開催レポート - 基調講演・特別講演 動画・資料一覧｜AWS Day2 基調講演（キーノート） 資料ダウンロード オープニングが例年のDJ田中氏から、三味線からのエレキギター＆バイオ リンとのセッションに変わりました。DJ田中氏は Day3,4 ？ 目立っていたのは先日ニュースにもなった、三菱東京UFJ銀行の事例。つ いに日本の銀行も AWS 上で動き始めました。とは言え、これから上り調 子か！と思わせてからのスピーカーの村林氏の今週末退任という流れには、 さすがに会場がザワッとしていましたw 去年との違いは Machine Learning 推しかなあ。 全体的に例年よりも RDS, Lambda など具体的な用語が多いキーノートだっ た気がします。そうできる状況になってきたのでしょう。 あとは Amazon Lightsail 東京リージョンの発表や、大阪ローカルリージョ ンの来年開設など軽めの発表でした。 詳細なレポートはクラスメソッドさんの記事をどうぞ。 【レポート】AWS Summit Tokyo 2017：Day2 基調講演(キーノート) #AWSSummit ｜ Developers.IO ナビタイムサービスにおける、Amazon ECS を活用したシステム移行　～『乗換NAVITIME』での移行事例 ～ 資料ダウンロード 3 月に ECS にズビっと移行したお話。CPU 負荷をトリガーに自動でスケー...

http://jawsdays2017.jaws-ug.jp AWS 歴 3 年にして初参加。AWS Summit 派だから…（震え 主にサーバレスやコンテナまわりを聞いてた。 以下、スライドを見て思い出したことなどのメモ。登壇者の方の敬称は略 でございます。 新訳 とあるアーキテクトのクラウドデザインパターン目録 登壇者: 山﨑奈緒美 登壇者: 神希嘉 登壇者: 金平晃尚 サーバレスやマイクロサービスの基本的でためになるお話。オンプレから クラウドに移行するモチベーションは理解できるけど、サーバレスはどん ななんでしょうかね？まだ解釈できていない。コンテナ化は分かるんだけど。 ひとりでも怖くない！コミュニティの広げ方 登壇者: 小深田あゆみ 懇親会でなんとか１人２人に話しかけることは出来るけど、そのまま話し 込んでしまうんだよなあ。切り上げ時が分からない。 サーバーレスでシステムを開発する時に大切な事 登壇者: 比企宏之 MBS動画イズム444 という動画配信サービスをサーバレスで実装したお話。 裏側にサイボウズの Kintone という CMS を置いて、表側をサーバレスで 実装したとのこと。要件定義から実装まで 3 ヶ月。 とにかく設計が大事ということを強調していた。 P6. 結合先（AWS）は信じない。Lambda が複数回発火することは知ってい たけど、発火しないこともあるとのこと。アプリケーションレベルでそれ を考慮した設計にしているとのこと。S3 のファイルを Lambda で処理し たら別のバケットに移動するとか。残っていたら発火してないので、定期 的に回収する。 P9. EC2 だとシステムが落ちると API も全部が落ちるが、サーバレスだ と一部の API が落ちることはあり得る。非同期処理を同調させる、分散 アーキテクチャを考える必要がある。 P11. サーバレスを採用すると、運用でカバーが出来なくなり、全部開発 メンバーに返ってくる。（DevOps しかやったことがないので、その辺り の感覚はよく分からないけど。） P15. できるだけ Lambda を使わないように設計。例えば有料会員以外は CloudFront と S3 のみでサイト表示させたり、フロントエンドでできる...

先日、ついに DynamoDB に TTL が実装されました。 新機能 – TTL（Time to Live）機能を利用したDynamoDBアイテムの管理について｜Amazon Web Services ブログ 仕事では Rails4 のセッションストアに ElastiCache for Redis を使っ ているのですが、[2016-10-24-1] に書いたとおり、スケールが辛いです。 作業自体もそうですし、ElastiCache for Redis はスケールアップのみで スケールアウトが出来ません。CPU パワーじゃなくてストレージが欲しい のじゃ…。 DynamoDB はインスタンスの管理が不要なため、もし移行出来たらとって もうれしいです。お値段も ElastiCache よりずっと安そうです。 https://aws.amazon.com/jp/dynamodb/pricing/ いろんな期待を込めて、ちょっと触ってみました。 準備 こちらの記事を参考にして、Rails4 のセッションストアを DynamoDB に します。 Rails4 でセッションストアに DynamoDB を使う ｜ Developers.IO 2013年11月05日と古めの記事ですが、現在も動くことを確認しました。 当時はまだ TTL が実装されていないので、 $ bundle exec rake db:sessions:cleanup で期限切れのデータを削除する方式です。 なぜか migration ファイルに拡張子 .rb が付かず、db:migrate で DynamoDB のテーブルが作られませんでした。適当にリネームして下さい。 DynamoDB に expired_at を追加 DynamoDB で expired_at フィールドを追加する修正をしてみました。...