omuronの備忘録

個人的な備忘録

Infra Study Meetup #2「VM時代の開発とCloud Native時代の開発」受講

今日は Infra Study Meetup です。

forkwell.connpass.com

ハッシュタグ#InfraStudy

YouTube Live 配信で、千人を超えてましたが安定して配信されてました。

https://www.youtube.com/watch?v=9YpN9-RCwWE

資料まとめ。

基調講演「VM 時代の開発とKubernetes による Cloud Native な開発のこれから」

speakerdeck.com

LT1「Scheduling Profile が実現する Pod 配置戦略の最前線」

speakerdeck.com

LT2「IaCだからこそ必要なドキュメントとは?」

speakerdeck.com

LT3「Cloud Native時代の開発環境デザインパターン

speakerdeck.com

LT4「DBプラットフォームの変遷 - ベアメタル、VM、そしてコンテナへ -」

speakerdeck.com

LT5「全てがクラウドネイティブで良いのか。その謎を明らかにすべく我々はエンプラの奥地に向かった(仮)」

資料はまだ公開されてない?
GAFA 社長がバーチャルネクタイを頭にまいて話してたので、ずーとそこに目が言ってしまった。

前日にまだ書いてないと言ってたのが信じられないクオリティで面白かった。

追記

speakerdeck.com

所感

基調講演では「5年後には全てのリソースがk8s上で動く! 」とのこと。
利用するサービスとしてはその部分を意識しないもののほうが多いだろうなーと思ってる。

LT2「IaCだからこそ必要なドキュメントとは?」 の回答を当てれて、同じようなことを最近はしていたのが嬉しかった。
Draw.io を VSCode プラグインでいれて、構成図書くのがすごい楽だったので、そのまま Git 管理している。
.dio ファイルをそのままコミットしてたけど、SVG 出力すると GitHub で見えるのでいいと言ってたので、必要に応じて SVG もコミットするようにしよう。

「JAWS-UG CLI専門支部 #153R SNS入門」受講

jawsug-cli.connpass.com

メールで簡単に通知するときに利用する SNS 入門です。 資料は connpass からリンクされている こちら

前回の SQS 入門の記事は こちら

SNS の説明

  • マルチリージョンで冗長化されている
  • プッシュ型 (SQSはプル型)
  • 疎結合のためのキーコンポーネント
    • お互い知らなくても処理できる
  • 1 : n の関係
    • SNS 1 に対して、受信はいくらでも増やせる
    • 疎結合のポイントとして、Publisher(SNS)は変わらなくても、受信者の拡張ができる
  • 受信者のことは気にしなくていいので、まずはメールが簡単
    • その後、 Lambda --> Slack などをトピックに追加すれば、複数サービスへの拡張もできる
  • 再配信(メールサーバー落ちてるときか)をしたい場合は、SQSのデッドレターにためて再送したりする

ハンズオン

CLI での操作とあわせて、マネジメントコンソールで出来上がったトピックを見ながらやるのがおすすめとのこと。 以下、記載内容はハンズオン資料を自分でやり直したメモ。 もとの資料のほうが丁寧なので基本的にはそちらを参照ください。
資料では、環境変数を多用していますが、今回は使わないで実施。

SNSトピックの構築

適当なトピックの名前 handson-cli-sns-topic で構築。

$ aws sns create-topic --name handson-cli-sns-topic
{
    "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:handson-cli-sns-topic"
}

作ったキューを確認する。

$ aws sns list-topics --query "Topics[?contains(TopicArn, \`handson-cli-sns-topic\`)].TopicArn" --output text
arn:aws:sns:ap-northeast-1:123456789012:handson-cli-sns-topic

マネジメントコンソールでも確認できる。

f:id:omron:20200519194539p:plain

SNSトピックの購読

メールで受信する手順。
メールアドレスは、自身で受信ができるもので確認すること。
以下のコマンドで、受信者を追加する。

$ aws sns subscribe --topic-arn arn:aws:sns:ap-northeast-1:123456789012:handson-cli-sns-topic --protocol email --notification-endpoint hoge@example.com
{
    "SubscriptionArn": "pending confirmation"
}

マネジメントコンソールで保留中のサブスクリプションが確認できる。

f:id:omron:20200519195913p:plain

設定したメールを確認すると subscribe の確認メールがくる。

f:id:omron:20200519195516p:plain

Confirm subscription のリンクをクリックして購読すると、「購読済み」になるのが確認できる。

f:id:omron:20200519200412p:plain

今設定した SNS トピックのサブスクリプション ARN の取得手順。
設定したサブスクリプションの削除をする場合などに利用。

$ aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:ap-northeast-1:123456789012:handson-cli-sns-topic --query "Subscriptions[?Endpoint == \`hoge@example.com\`].SubscriptionArn" --output text
arn:aws:sns:ap-northeast-1:123456789012:handson-cli-sns-topic:53b77286-f5af-4320-84ea-XXXXXXXXXX

SNSトピックへのメッセージの配信

--message に本文を指定する。
メールに送信する場合は題名も --subject で設定することができる。

$ aws sns publish --topic-arn arn:aws:sns:ap-northeast-1:123456789012:handson-cli-sns-topic --message "Hello World" --subject "Message handson-cli-sns"
{
    "MessageId": "000ca175-27e5-5745-850c-XXXXXXXXXX"
}

メールを確認すると、「Hello World」のメールが確認できる。

f:id:omron:20200519200830p:plain

フッターに、アンサブスクライブのリンクがあるので、注意する必要がある。
間違えて、アンサブスクライブしても、再度サブスクライブするメールを受信するので、復旧は可能。

f:id:omron:20200519202645p:plain

アンサブスクライブのリンクは設定で消すことができるんじゃないかなとのこと。
近しい事例がブログの会社の記事にがありました。

dev.classmethod.jp

所感

環境変数を多用するのは、実際の作業での差異をなくすために改善していった結果とのこと。
無心で作業をしてもらうには非常に効率的でいいと思いました。
一方、自身で確認するときには「何を設定してたっけな?」となってしまったので、使わない方法で試しました。
SNS トピックは、GurdDuty の通知などエラー系通知で利用するのがメインかなー。
基本的に通知されたくないが、緊急で知りたいもので利用しているケースが多い感じです。

「【オンライン開催】DMM.go #2」参加

今日は DMM.go です。

dmm.connpass.com

ハッシュタグ#dmm_go

YouTube アーカイブされるとのこと。

www.youtube.com

備忘録程度のメモ。

Goaを使ってAPIサーバ開発してみた

  • yaml は辛い
  • 自動生成したファイルはgit管理しない
  • 手元では docker で見ている
  • golint 遵守すると dot import で怒られる

Goとクリーンアーキテクチャ

  • 依存関係逆転の原則
  • 抽象は実装の詳細に依存してはならない
  • 実装の詳細が抽象に依存すべきである
  • フロントエンドとバックエンドの分離
  • バックエンドは永続層からデータを取ってフロントに渡すだけ

2万rpsを処理する行動ログ収集システムをGoで作った話

  • Go はコンテナネイティブ・速度が出せる

「Auth0 ユーザーコミュニティ Online Meetup」参加

今日は、1時間の短時間 Auth0 オンラインミートアップでした。

auth0-japan.connpass.com

Zoom による開催で、 「カメラオンにして必要であれば音声もオンにして質問もしてください。」
とのことだったけど、カメラオンにしている人が主催者以外で見当たらなかった気がしました。
設定で他の人には見えないようにとかだったんだろうか?
オンラインでのミートアップってむずかしいなーと感じました。

Auth0 新機能アップデートメモ

  • セッションとプロトコル
    • リフレッシュトークンのローテーション
    • 鍵のローテーション
  • ユーザー管理
    • パスワードハッシュインポート
  • 拡張性
    • Management API の Hook 対応
  • Auth0 Signals
    • リスク分析エンジン
    • 買収した企業の技術
    • ブラックリストIPや普段アクセスの無い国のIPなどをみてスコアリング
    • Slack からも利用可能
  • パブリッククラウド
    • SMS Twillio 以外も利用可能に
    • Node.js version 12 対応。
      • 現行テナントは 8 がデフォルト
      • 新しいテナントを作った場合は 12 がデフォルト

忘却の彼方の Dockerfile 作成

久しぶりに docker イメージを作ろうとしたけど、忘却の彼方でした。 思い出しついでの作業メモ。

新規 Docker 起動の作業メモ

Dockerfile 作成

適当なディレクトリ作って Dockerfile を作る。

$ mkdir docker; cd docker;
$ vi Dockerfile

よく docker でつかう alpine を設定。

FROM alpine:3.10
SHELL ["/bin/ash", "-eo", "pipefail", "-c"]

ビルド

現在のディレクトリ指定してビルド。

$ docker build .

イメージができてるか確認。

$ docker images | head
REPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
<none>                                  <none>              3b9e46db4286        10 seconds ago      5.58MB

タグ付け

呼び出しやすいようにタグ付けして、ちゃんとついたか確認。

$ docker tag 3b9e46db4286 test/alpine:3.10
$ docker images | head
REPOSITORY                              TAG                 IMAGE ID            CREATED              SIZE
test/alpine                            3.10                3b9e46db4286        About a minute ago   5.58MB

実行

alpine は bash じゃなくて ash なのを注意して起動。

$ docker run --rm -i -t test/alpine:3.10 /bin/ash

--rm つけておけば、無駄にプロセス残らない。

--rm コンテナ終了時、自動的に削除
-i コンテナの STDIN にアタッチ
-t 疑似ターミナル (pseudo-TTY) を割り当て

イメージ削除

もう必要がないイメージは消してしまう。

$ docker rmi test/alpine:3.10

所感

マウントするための -v や、ポート指定の -p とかも起動オプションでよく使います。 イメージから作ることってあまりないし、docker compose でまとめちゃうからすっかり忘れてしまってた。

100均アイテムを利用してノートパソコンスタンド代用

新しい MacBook Pro 13 インチでましたね。 キーボードが改善されて、Vimmer には嬉しい物理 ESC キーも搭載です。

現在仕事で利用している MacBook Pro 13 インチは、Late 2017 です。 このモデルは、キーボードも薄くて打ちづらく、ESC キーもタッチバーで打鍵感などありません。 ゆえに、HHK Lite を外付けして利用しております。

f:id:omron:20200511204804j:plain

利用しているパソコンデスクには、キーボードを置く場所があるのですが、位置が低くて一日使っていると肩がこります。 しかしスペース的に、机の上に置くこともできません。 ノートパソコンスタンド買おうと迷ってたのですが、そこそこいい値段がするのでどれがいいか迷っていました。

そんな折に、たまたま先日 100 均に寄った際に、代替になりそうな物が目に付きました。

f:id:omron:20200511205644j:plain

そう、本立てです。 別のブログでも本立てをノートパソコンスタンドに代用しているのを見たこともあり、とりあえず買ってみました。 角度的に立ちすぎてたため、ちょっと力を入れて変形させて、高さ確保に本で調整しました。

f:id:omron:20200511205741j:plain

十分いい感じです。 机の上にキーボードがおけるので、だいぶ打ちやすくなりました。

 「JAWS-UG CLI専門支部 #152R SQS入門」受講

jawsug-cli.connpass.com

非同期キュー処理でお世話になる SQS 入門です。 SQS は使っているけど、自分で構築したことがなかったので受講しました。 資料は connpass からリンクされている こちら

AWS 全般の説明

  • AWSの勉強は公式ドキュメントが基本
    • ただし、サービスごとに書いているチームが違うので差はある
  • サポートも質の割には値段が安いのでぜひとも契約を
    • 注意としては特定事象の問合せは契約アカウントのみに限るところ

ハンズオン

CLI での操作とあわせて、マネジメントコンソールで出来上がったキューを見ながらやるのがおすすめとのこと。 以下、記載内容はハンズオン資料を自分でやり直したメモ。 もとの資料のほうが丁寧なので基本的にはそちらを参照ください。

新しいキューの作成

適当なキューの名前 SQS_QUEUE_NAME="handson-cli-sqs-queue"環境変数に設定して新しいキューを作る。

$ aws sqs create-queue --queue-name ${SQS_QUEUE_NAME}
{
  "QueueUrl": "https://queue.amazonaws.com/XXXXXXXXXXXX/handson-cli-sqs-queue"
}

作ったキューを確認する。

$ aws sqs list-queues --queue-name-prefix ${SQS_QUEUE_NAME} --query "QueueUrls[?contains(@, \`${SQS_QUEUE_NAME}\`)]" --output text
https://queue.amazonaws.com/XXXXXXXXXXXX/handson-cli-sqs-queue

キュー属性の変更

VisibilityTimeout は、不可視属性(処理中に見えなくなる)時間の設定。 1分にする場合 VisibilityTimeout=60 をパラメータにわたす。 先程作ったキューのURLも SQS_QUEUE_URL に取り出して処理をすると楽。 set-queue-attributes で設定を行う。

$ SQS_QUEUE_URL=$( aws sqs get-queue-url --queue-name ${SQS_QUEUE_NAME} --output text )
$ aws sqs set-queue-attributes --queue-url ${SQS_QUEUE_URL} --attributes  VisibilityTimeout=60

確認は、 get-queue-attributes

$ aws sqs get-queue-attributes --queue-url ${SQS_QUEUE_URL} --attribute-names VisibilityTimeout --query "Attributes.VisibilityTimeout" --output text
60

メッセージの送信

send-message でメッセージ送信

$ aws sqs send-message --queue-url "${SQS_QUEUE_URL}" --message-body "Hello World!"
{
    "MD5OfMessageBody": "b10a8db164e0754105b7a99be72e3fe5",
    "MessageId": "0a0ac318-9fd7-4590-9f28-XXXXXXXXXX"
}

MD5 と MessageId がとれる。SQS は、重複して送信される可能性があるから MessageId は大事。

AWS コンソールで確認すると 利用可能なメッセージ が増えているのが確認できるはず。 CLI で取得する場合はこう。

$ aws sqs get-queue-attributes --queue-url ${SQS_QUEUE_URL}  --attribute-names ApproximateNumberOfMessages  --query 'Attributes.ApproximateNumberOfMessages'  --output text
1

メッセージの受信

receive-message でメッセージ受信。

$ aws sqs receive-message --queue-url "${SQS_QUEUE_URL}"
{
    "Messages": [
        {
            "MessageId": "0a0ac318-9fd7-4590-9f28-XXXXXXXXXX",
            "ReceiptHandle": "XXXXXXXXXX,
            "MD5OfBody": "b10a8db164e0754105b7a99be72e3fe5",
            "Body": "Hello World!"
        }
    ]
}

繰り返して receive-message すれば、メッセージが存在する数だけ取得できる。 不可視属性の時間の間は、同じメッセージは基本取得できない。 不可視属性の時間を経過すると再度取得できる。 重複を考えて、 MessageId に注意して処理をする必要がある。

処理したメッセージは、キューから削除。 SQS_MESSAGE_RECEIPT_HANDLEreceive-message で取得したハンドルが必要。

$ aws sqs delete-message  --queue-url "${SQS_QUEUE_URL}"  --receipt-handle ${SQS_MESSAGE_RECEIPT_HANDLE}

キューの削除

本番運用では不要の項目。テストでキューを作った場合は削除する。

aws sqs delete-queue  --queue-url ${SQS_QUEUE_URL}

所感

ハンズオン後のコメントで「SNS のほうがもっとわかりやすい。」「AWS は IAM に始まって IAM に終わる。」と言ってました。 SQS は、メッセージの重複や順番が保証されないなど、デフォルトの設定では気にする点もありますが、複数のサービスを非同期で処理するときには便利な印象です。 SNS では難しい場合に利用を検討すればいいかな。