omuronの備忘録

個人的な備忘録

「AWSの基礎を学ぼう 第六十三回 AWS Outposts」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

AWS の離れ小島として専用リージョンを物理サーバーとして買うことができる Outposts の回です。

セッション

AWS Outposts おさらい

講師：アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

クラウドは適さないもの

  • TCP/UDP を使ってない
  • 法律でデータを国外に出してはダメなケース
  • マイクロ秒で動かすもの

これらのケースは、Outposts 向け。

Outposts ラック

  • 42Uラック
    • 203 x 61 x 122 cm, 5 - 15kVA の電源
    • 1U,2U の小さいものも追加された
  • EC2 とか S3 とかセットアップした状態で送られてくる
    • S3 の API が使えるオブジェクトストレージが使える
      • 複数 AZ へのコピーがされるわけではないので堅牢性とかは無い
  • AWS の1つの AZ として存在するイメージ
    • AWS のマネコンで操作できる
    • 新しい AZ ID が振られる
  • 10Gとかの Direct Connect とセットで使われることが多い
    • public VIF, Private VIF
    • ISP 経由のインターネットも可能だけど遅いしセキュアじゃないのであまり使われない

セキュリティ

  • 耐タンパー性
    • 開けると壊れる
    • 盗まれるぐらいなら破壊する
  • バックアップはクラウドに保存すること
    • Outposts は低遅延用途なのでクラウドに置けないデータを管理するために使うものではない

所感

と、思い出してまとめながら資料を見直そうとしたら、今日の資料を保存してなかった...ショック。

まぁ Outposts じゃ買うことはそうそうなさそうですが、AWS の一部を自前で持てるというだけで夢がありますねー。
中身を開けると壊れてしまうという自爆装置つきなのもすごい。

rain でプロファイル指定ができない

小ネタ AWS

CloudFormation を CLI で簡単に使える rain を触ってみました。

github.com

インストール

$ brew install rain
$ rain --version
Rain v1.2.0 darwin/amd64

プロファイルを指定して試す

-p でプロファイルが指定できるけど、エラーになってしまった。

$ rain ls -p poc
unable to find valid credentials

--debug オプションを付けるとどこで panic したかわかるようです。

$ rain ls --debug -p poc                   
panic: unable to find valid credentials [recovered]
    panic: unable to find valid credentials

goroutine 1 [running]:
github.com/aws-cloudformation/rain/internal/cmd.execute.func1(0xc000587f58)
    github.com/aws-cloudformation/rain/internal/cmd/wrap.go:77 +0x225
panic(0x18d5700, 0xc00012e720)
    runtime/panic.go:965 +0x1b9
github.com/aws-cloudformation/rain/internal/aws.loadConfig(0x1fc9a90, 0xc000024258, 0xc000126600, 0xb, 0x1)
    github.com/aws-cloudformation/rain/internal/aws/aws.go:80 +0x906
github.com/aws-cloudformation/rain/internal/aws.NamedConfig(0xc000126600, 0xb, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    github.com/aws-cloudformation/rain/internal/aws/aws.go:114 +0x149
github.com/aws-cloudformation/rain/internal/aws.Config(...)
    github.com/aws-cloudformation/rain/internal/aws/aws.go:95
github.com/aws-cloudformation/rain/internal/cmd/ls.glob..func1(0x2302560, 0xc000594a20, 0x0, 0x3)
    github.com/aws-cloudformation/rain/internal/cmd/ls/ls.go:44 +0x368
github.com/spf13/cobra.(*Command).execute(0x2302560, 0xc0005949f0, 0x3, 0x3, 0x2302560, 0xc0005949f0)
    github.com/spf13/cobra@v1.1.3/command.go:856 +0x2c2
github.com/spf13/cobra.(*Command).ExecuteC(0x2302ce0, 0xc000042740, 0x1068aa8, 0xc000000180)
    github.com/spf13/cobra@v1.1.3/command.go:960 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
    github.com/spf13/cobra@v1.1.3/command.go:897
github.com/aws-cloudformation/rain/internal/cmd.execute(0x2302ce0, 0x0)
    github.com/aws-cloudformation/rain/internal/cmd/wrap.go:86 +0x65
github.com/aws-cloudformation/rain/internal/cmd.Execute(0x2302ce0)
    github.com/aws-cloudformation/rain/internal/cmd/wrap.go:95 +0x2b
main.main()
    command-line-arguments/main.go:23 +0x2d

どうやら .aws/config の source_profile の行をつけていると問題になるっぽいので、削除して実行するとうまくいきました。

$ cat .aws/config
[profile poc]
region = ap-northeast-1
mfa_serial = arn:aws:iam::123456789012:mfa/omuron
role_arn = arn:aws:iam::123456789012:role/xxx
source_profile = poc

うーん、でも source_profile を消すと通常の aws コマンドのときに困るんだけど。
この辺りの理解が正しくないんだろうか？

雨が降るようなプログレスがかわいい rain ですが、仲良くするためにはまだ修行が足りないようでした。
精進します。

「AWSの基礎を学ぼう 第六十二回 AWS CodeArtifact」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

コードシリーズの最後となる CodeArtifact です。

セッション

AWS CodeArtifact おさらい

講師：アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

CodeArtifact とは

Code シリーズの「Soure/Artifact」に分類される。

  • CodeCommit : プライベートリポジトリ
  • CodeArtifact : プライベートソフトウェアパッケージリポジトリ
    • パブリックに公開できないパッケージを保存
    • パブリックのパッケージマネージャのプロクシとして動作させることができる

対応言語/パッケージマネージャ

ドメイン

  • 最上位の管理単位
  • パッケージの格納する単位として設定する
  • パッケージが複数のリポジトリに存在していても、保存はドメインごとに一度だけでいい
  • kms で暗号化可能
  • クロスアカウント対応なので、別アカウントのリポジトリも格納可能

リポジトリ

  • 必ずドメインに所属する
  • ドメインに格納されたパッケージにアクセスするためのエンドポイント
  • リポジトリは、他のリポジトリのアップストリームになることができる
  • 認証（ログイン）すればあとは npm とかと同じように意識せずに利用できる
    • ログイン後であればnpm publish とかで保存できる
# Login
aws codeartifact login --tool npm \
  --domain "my-orgW --domain-owner "account-id" \
  --repository "my-repo"

# Build
npm run build

# Version
npm version $VERSION

# Publish
npm publish

所感

なるほど、プライベートなパッケージを共有する仕組みなんですね。
普段の開発で npm とか pip とかは使うのですが、使うだけで自分でパッケージとして作ることがありませんでした。
複数人で開発している時に、別チームとかにパッケージだけを公開したい場合に有用なサービスだと認識しました。
こういうケースでは今までは Git リポジトリごと共有してたのですが、これを使えばパッケージとして共有できるということですね。

「AWSの基礎を学ぼう 第六十一回 AWS CodeStar」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

Code シリーズで、よくわからないサービス第1位（自分調べ）の CodeStar です。

セッション

AWS CodeStar おさらい

講師：アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

CodeStar

  • 側だけのサービス
    • 実態は Code シリーズなどの別サービス
    • 他のサービスと繋げるだけ
      • CodePipeline より上の概念

CodeStar 概要

  • CI 環境の作成が可能
  • チームをまたがった開発ができる
    • 簡易的なチケット管理
      • GitHub, Jira 連携
        • GitHub Actions 利用して無理やりほかの課題管理と連携
  • テンプレートから CI/CD を自動で生成可能
    • AWS リソース、アプリケーションタイプ、言語などから選択
  • CodeStar の利用は無料
    • 実際に使うリソースへ課金

プロジェクトダッシュボード

  • IDE
    • Cloud9 以外も設定可能
      • AWS Toolkit を利用して VSCode とかと連携できる
  • リポジトリ
  • パイプライン
    • CodePipeline そのまま
  • モニタリング
    • CloudWatch 表示
  • 問題（統合メニュー）
    • GitHub の Issue が見える
  • アプリケーションの表示（App エンドポイント）

所感

マネジメントコンソールから、簡単に GitHub と連携して CI 環境を作る場合は有用なサービスですかね。
Code シリーズの中でも、後から追加された CodePipeline や CodeStar はあまり使い慣れてないので経験が不足してます。
CodePipeline から設定するよりも、CodeStar 経由のほうが簡単に作れるのかな。

CloudFormation を利用していると、Code シリーズの設定をしている時に Chatbot と連携する場合とか思いもかけないところで CodeStar リソースを指定するケースが出てきたりします。
「CodeStar の実態は別サービス」と言ってたとおり、どの Code シリーズにも当てはまらず、つなぎ合わせる場合などに登場している気がしました。

「JAWS-UG朝会 #25」 #jawsug_asa 受講メモ

AWS 勉強会

JAWS-UG朝会 #25

jawsug-asa.connpass.com

セッション

セッション① Pay管理スキルとPay修正ページを作った話

フォージビジョン株式会社 尾谷 紘平さん

子供のゲーム時間管理

  • 管理方法
    • Switch : みまもり Switch
    • iPad : スクリーンタイム
    • PS4 : できず
  • ゲームの時間
    • 自分で時間を管理/創出するほうが自主性的に良い
  • お手伝いで Pay(ゲーム時間) 獲得
    • 管理情報の手入力めんどくさいから Alexa で実装

システム構成

  • Echo で入力、Slack 経由でスマフォに通知
  • Alexa Skill + Lambda + DynamoDB を CFn で構築
    • 言葉の揺れは複数のワードで対応
      • ウェイクアップワードは1つしか登録ができない

PDCA

  • 聞き間違いが発生
    • 修正対応がめんどくさい
    • 管理画面作成
      • S3 + CF + APIG + Lambda で簡易実装
      • 改善対応：Amplify/Vue.js + Cognito を追加GitOps運用

まとめ

  • Alexa 道場で勉強
  • Amplify で爆速フロントエンド
  • Admin UI で管理者サイト
  • 子どもたちと一緒にルール作りで家庭円満

子どもたちでもわかりやすくできるように、音声対応しつつ保守用の管理者サイトもちゃんと作っていくという。
PDCA まで回して改善して、家族向けサービスのレベルを超えていますね。 凄すぎワロタ状態でした。

セッション② AWS公式チュートリアルから始めるAWS StepFunctions

クラスメソッド株式会社 あしさん

speakerdeck.com

アウトプットしよう

  • ハンズオンでのアウトプット、CLI専門支部より
    • 完了させることを優先（全体把握）
    • 必ず復習（インプット）
    • 自分なりにカスタマイズしてオリジナル手順にする（アウトプット）

AWS 公式チュートリアル

  • リソースやキーワードで検索可能
  • 「サーバーレスアプリケーションでエラーに対処する」を実践
    • Step Functions が入っている

Step Functions

  • アップデート前：JSON形式のみ
  • アップデート後：WorkFlow Studio で GUI 可能に
  • 公式チュートリアルをアウトプットしようの手順に沿って行った
    • StepFunctions ステートマシン作成
      • ステートマシンのテスト
        • グラフインスペクターで可視化される
    • 復習
      • 使用したコードのフロー図作成
        • あえて作ることで理解が深まる
      • StepFunctions State 調べる
        • Task, Pass, Wait, Parallel, Choice, Map, Fail, Succed
    • 改良版ハンズオン手順作成
      • ハンズオンはコードで作ったので、WorkFlow Studio で作り直し
      • テストを Cloud Shell から CLI で実行できるように

まとめ

  • 全体把握、インプット、アウトプットで学習
  • 公式チュートリアルは良い
  • Step Functions は使いやすくなった

「完了優先」「復習」「改善とアウトプット」とわかってはいるものの難しいですね...
自分的には復習が難しくて、業務で利用するなどが無い限り復習のモチベーションは上げるのが難しいと感じます。
アウトプットも出すだけならできても「改善」となると大変で、使うべき理由がないとなかなかできてない。
CLI専門支部の波田野さんは本当にすごいと思います。

LT① aws nuke触ってみた

富松 広太さん

www.slideshare.net

AWS nuke

  • リソースを全て削除できる
  • AWS アカウントを持ってない人向けのハンズオンで活用
    • アカウントを消すのはめんどくさい
    • root で Organizations から切り離して消すのが大変
  • 親アカウントから子アカウントへ Switch Role して Nuke 実行をループさせる
    • Nuke Config で削除の例外登録可能
    • Organization で保護対応で例外対応

アカウントを綺麗サッパリしたいシチュエーションがあまりなさそうなので、 nuke は、取り急ぎは使う機会はなさそうかな。
勉強用アカウントをクリアーしたいときがあれば利用しよう。

LT② SNSのサブスクリプションが消せない！

emiさん

speakerdeck.com

SNS Topic

  • Eメールのエンドポイントを typo した
    • サブスクリプションが登録も削除もできない
    • 3日後に自動で削除されるというしようのはず
      • いつまでも消えない
      • サポート契約して聞くことに
        • 数十日で消えるはず
        • サポートで消してもらった

AWS のサポート費用って、業務だと高くはないですが、個人だとそこそこ高くないですか？
同じような状況になると気になってしまいそうですが、躊躇なく勉強代として払えるのがすごい。
こういう状況になったらアカウントごとクローズしてやり直しそうです。

LT③ ふまんがあります（CFn と CDK でハマりまくった話）

Tech Do 塚原さん

speakerdeck.com

ふまんがあります

  • ヨシタケシンスケさんのユーモア絵本
  • 良い文句と悪い文句がある
    • 良い文句：フィードバック、事実、リスペクト
    • 悪い文句：クレーム、理不尽、ハラスメント
  • ふまんをじょうずにつたえよう

CDK の不満

  • $(AWS_PROFILE) が効かない
    • デフォルトプロファイルが効かない
      • 今は効いている？
    • profile 定義して指定が必要
  • エラーメッセージが分かりづらい
    • -v で詳細ログ出力
    • そこでみればわかる
  • High / Low Level Construct を混ぜれない
    • ほとんど High と Low が準備されている
    • ElastiCache は Low しかない
      • 2回に分けてデプロイが必要
  • 重い
    • CFn テンプレート変換コストが高くて10分ぐらいかかることもざら

CDK 展開は確かに重たいから改善されていくといいですね。
High / Low Level Construct 混ぜれないことに関しては、自分はリソース思考でスタックを作りがちなのでそこまで困らないかなー。 アプリケーション思考にしたい場合は、困ることになりそうだけど。
あと、 -v での詳細ログは使っとこが無かったです。
マネコンに入って、CFn のエラーを直接見に行くことが多いかな。

所感

どのセッションも面白く勉強になりましたので、個別に所感を挟んで書いてみました。

High / Low Level Construct 混ぜれないことに関しては、自分はリソース思考でスタックを作りがちなのでそこまで困らないかなー。 アプリケーション思考にしたい場合は、困ることになりそうだけど。

この辺りは、色んな意見を聴いてみたいから、次回登壇しようかなと深く考えずに申し込んでみる。

「AWSの基礎を学ぼう 第六十回 AWS CodeDeploy」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

CodeDeploy って、（CodePipeline 準備した上で） AppSpec.yml を準備するのが大変じゃないですか？

セッション

AWS CodeDeploy おさらい

講師：アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

Push 型と Pull 型のデプロイ手段

自動化を実現するには、Pull 型のデプロイが推奨される

  • Push 型
    • デプロイ先を知る必要あり
  • Pull 型

CodeDeploy コンポーネント

  • アプリケーション
    • CodeDeploy の識別名
  • コンピューティングプラットフォーム
    • EC2/オンプレミス
      • エージェント必要
    • Lambda
    • ECS
  • デプロイグループ
    • デプロイ環境定義
      • Auto Scaling グループ
      • タググループ（EC2/オンプレ）
      • ECS サービス
  • デプロイタイプ
    • In-Place
      • All at Once
      • まとめておきかえ
      • 1台ずつの場合はローリングデプロイともいう
    • Blue/Green
      • 新規にノードを構築して、リクエスト先を振り分け
  • デプロイ設定
    • EC2
      • One-at-a-time
        • まとめて切り替え
        • カスタム可能
      • Half-at-a-time
      • All-at-once
    • Lambda/ECS
      • Linear
        • 25%最初振り分けたあと、10分後25%ずつ新規に振り分け率を増やす
      • Canary
        • 25%最初振り分けたあと、10分後まとめて新規に移行する
      • All-at-once
        • 最初から全部新規へ移行
  • リビジョン
    • EC2
    • Lambda
      • Lambda デプロイ用 AppSpec ファイル
    • ECS
      • ECS デプロイ用 AppSpec ファイル
  • ターゲットリビジョン
    • リポジトリにアップロードした直近のリビジョン
    • デプロイグループへデプロイする対象
    • 自動デプロイで取得されるリビジョン
  • サービスロール
    • CodeDeploy に付与する IAM ロール
    • CodeDeploy から AWS リソースを操作するために必要
  • IAM インスタンスプロファイル
    • EC2 インスタンスに付与する IAM ロール
    • S3 から取得できるようにする

EC2/オンプレのデプロイ

Lambda のデプロイ

ECS のデプロイ

  • Blue/Green が基本
    • Green タスクをプロビジョニングしてLBのトラフィック切り替え
    • Test traffice listener (ECSの標準機能)
      • ECS で事前に作る必要ある
  • タグ付け
    • latest は使うべきではない
      • 切り戻しできなくなる
      • スケールアウト時に未テストのコードがデプロイされる
    • イミュータブルなタグを使ってデプロイ
      • sha256 digest やビルドIDを流用してタグ付け

所感

CodeDeploy は、対象が EC2 だとエージェントいれて準備する必要があり、アプリケーションエンジニアと協業して行う部分がインフラエンジニアとしては少し大変だなーという印象があります。
CodeBuild を利用して Push 型で作りがちで、CodeDeploy に慣れてなく経験不足なだけですが、一度作っちゃうと CodeDeploy も便利なのは確かですね。
Git と連携してデプロイする場合、CodeBuild はそのまま Git からフックできますが、CodeDeploy は CodePipeline が必須なのも、あまり使わなくなる理由の1つです。
（個人だと CodePipeline にお金使うのがちょっとだけもったいない）

ECS だと、CodePipeline を利用すれば直接デプロイ可能なので、ローリングデプロイで困らなければ CodeDeploy は不要と思っています。
CodeDeploy をあえて利用する理由は Blue/Green デプロイをしたかったり Hook スクリプト利用してロールバックをしたいケースでしょうか？
プロダクション環境で安全にコンテナを差し替えする場合は、CodeDeploy をちゃんと使うほうがいいと思っていたほうが良さそうかな。

CodeDeploy への愛と理解が足りてないことを思い知らされる回でした。

「nakanoshima.dev #21 LED!! (Let's enjoy データ分析!!)」 #nakanoshima_dev 受講メモ

AWS 勉強会

nakanoshima-dev.connpass.com

データレイク活用したいしたい詐欺で全然できてません。

セッション

小さく始めるデータレイク

池田 敬之氏 (Amazon Web Services Japan)

データレイク

  • すべてのデータを一元的に保管するのが大事
  • S3 をデータレイクのコアとして考える
    • 対障害性など利点あり
ポイント：小さく段階的に始める
  1. 土台： S3, Glue
  2. 最小限のデータ分析： Athena, Glue Crawler, Glue Data Catalog
  3. 可視化： QuickSight
  4. 大規模化： Redshift, EMR
  5. 民主化： LOB, BI, Glue DataBrew
  6. 高速化： クエリ/置き方の最適化、チューニング、高速化、リアルタイム処理
  7. AI/ML： SageMaker, Forecast...

ETL - AWS Glue

  • サーバーレス
  • GUI でコードが書ける Glue Studio
  • データソースのメタデータ管理

デモ

S3 をデータレイクとして、AWS Glue で Data Catalog 化して、Athena で検索したのを QuickSight で可視化する。

  • Glue でのカタログ化
    • Database 作成
    • データベース - テーブルに作成される
  • Athena で検索
    • データソースに AwsDataCatalog
    • ビューの作成でネストした内容を展開
  • QuickSight と接続
    • データベース/ビューと接続可能

Amazon MWAA を導入しようとした話

西谷 圭佑氏 (シルバーエッグ・テクノロジー株式会社)

Amazon MWAA

AWS＋Tableauで「誰もが使えるデータ分析基盤」を！

中南 臣吾氏 (株式会社セールスフォース・ドットコム Tableau)

誰もが使えるデータ基盤

Tableau のモットー We help people see and understand data!

  • 必要な時にすぐアクセス
  • 常に最新データ
  • 大量データでも高速に分析
  • SQLかけなくても簡単に

Tonamelのデータ基盤　〜データモデリング編〜

池田 将士氏 (面白法人カヤック)

Tonamel

  • 大会開催するときに利用するプラットフォーム
  • データ基盤：DynamoDB + Aurra -> S3 -> Redshift -> Redash/Slack
    • 問題が出たので改善
    • MWAA + Redshift へ

データ基盤運用問題

  • データ基盤運用問題
    • Git Flow で開発
    • データ基盤は Production のみ
      • ロジックやデータ構造変化の修正が大変
    • ETL は SQL
      • コピペSQL増加
  • dbt_ で解決
    • データ変換ツール
    • OSS, Python Jinja2 記法の SQL ビルダー/ランナー
    • 超便利ツール！

所感

「小さく始めるデータレイク」のデモがとてもよかったです。
Athena って、テーブル作るのがめんどくさくて大変なイメージがあるのですが、Glue でもテーブル作れるんですね。
QuickSight は可視化するだけならあまり考えずにできるんですが、ちゃんと必要なデータを表示しようとすると元ネタを作るのに困る状況でした。
こちらも Glue で作って連携できるんですね。
Glue を全く触ったことがなかったので、これを機会に試してみたいと思います。