omuronの備忘録

個人的な備忘録

（小ネタ） AWS CLI v2 のページャー出力をやめたい

小ネタ AWS

CLI v2 のページャー出力はその場で表示を見るのは楽ですが、ファイル等に出力するときはじゃまなので切る方法を探しました。
ここ に記載があります。

結論としては ~/.aws/config に以下の設定を追加すれば解決しました。

[default]
cli_pager=

追記

環境変数でも消せるようです。

export AWS_PAGER=""

「CloudNative Days Tokyo 2020 Recap」 #CNDT2020 受講メモ

AWS 勉強会

cloudnativedays.connpass.com

去年は東京までいって参加したのですが、今年はオンラインも見れなかったので Recap があって助かりました。
ということで、気になる部分の受講メモです。

モノリスからクラウドネイティブへ - 設計思想の違いを知り乗り越える

講師：山本 泰宇

原則駆動開発 (PDD) pdd.dev

  • Be Declarative
  • Define by Software
  • Test Everything

誘導された開発成果

  • 仮想データセンターによる CI/CD Test Everything
  • k8s 自体 GitOps で更新 Be Declarative
  • ストレージネットワーク on k8s Define by Software

何を使うかよりどうやっていくかが大事

開発モデル

コンセプト検証 (PoC)

対策

  • 工数はよまない
    • 順番だけ決める
  • 積み上げた成果を利用者に順に提供
  • 改善作業専任チーム

学習

  • 輪講や勉強会を業務時間に
  • KubeCon に全員派遣
  • アウトプット
    • ブログやミートアップで成果発表

OSS

  • アップストリームへの貢献
  • 頻繁なアップデートへの対応
    • 更新試験の自動化は必須
  • OSS ポリシー、ガイドラインを整備

まとめ

  • アーキテクチャ：何を使うかよりどう使うか
  • 運営：作って終わりではなく作り続ける
  • 人材：専門家を育成するより組織作り
  • OSS：社員の支援とテストの充実

独りよがりのプラットフォーム

講師：原 トリ

リアルトリさんの公演です！
（一度リアルで会ったことはあるけど）

プラットフォームの話をしましょう

プラットフォームの類義語

  • 共通基盤
  • インフラ基盤
  • 次世代開発プラットフォーム
  • 次世、統合、インフラ、共通、開発、基盤...

共通基盤

  • 実現方法の話し合いから２年たった
    • 陳腐化してきた
    • k8s きてる？

うまくいかない共通基盤

  • 課題設定は大きくふわっと
  • ユーザーヒアリングは無駄
  • 課題解決できるかは計測せず雰囲気
  • 共通基盤は使わせるもの
  • 共通基盤は作りきり

共通基盤と課題設定

  • 現実とかけ離れたでかすぎる TODO リストは終わらない
  • タスクに落とし込める課題設定が必要
  • Acceptable なゴール設定

共通基盤とステークホルダー

  • 基盤を取り巻く人々が抱えている課題はそれぞれ異なる
  • ユーザーヒアリングがとにかく大事
    • 何困っているか？（何が欲しいかではない）
    • 原因の解消方法の仮説立て
    • ユーザーに提案して意見もらう
      • 実装はしない
      • ホワイトボーディングやドキュメント
      • ユーザのフィードバックで修正
    • MVP での実装

どうやって AWS をつくってきた？

  • 90 - 95% の新機能はユーザーリクエストをベースに作成
    • 仮設を立ててヒアリング
    • 内部の声はカウントされない
      • どこの顧客がいっているんだ？とヒアリングされる
      • 別のサービスのチームは「ユーザー」
  • お客様を起点に考える
    • プレスリリースを最初に必ず書く
    • リリースに対する FAQ を実装前に書く
    • 顧客視点で課題が解決できるか確認するプロセス

なぜ計測可能な課題設定が重要なのか？

  • プラットフォームとチームの存続意義
    • ステークホルダーへの説明責任
    • 成果のない基盤チームはただの負債
    • 計測できない成果は成果ではない
  • 計測できないものを課題として設定しない
    • e.g. コスト削減、生産性バク上げ、モダン、クラウドネイティブ、超セキュア

共通基盤はなぜ使われないか

  • 必要ないものを無理に使わせる
  • 説明ニグレクト
  • 最初は良さげに見えたが新たな課題や世の中の流れについていかない

誰のための共通基盤なの？

価値のある意味にあるプラットフォームを

  • 適切な粒度の課題設定
  • 共通基盤のステークホルダーは顧客
  • ひたすらユーザーヒアリングと MVP の繰り返し
    • 顧客から逆向きに課題を探り出すべし
  • 計測、計測、計測
    • 何を計測するかはすぐには見えない、メトリクスを見つけるもの大事な仕事
  • 共通基盤は社内向けのサービス
    • 継続的に改善、継続的にユーザーヒアリング
  • 形のある基盤という存在にこだわらない

所感

どちらの話もとてもささりました。
適切な粒度や MVP での実装は意識している。
ヒアリングと計測...これはわかっているけど難しい。
計測は意識しやすいけど、プロダクトオーナーが近くにいないとかを言い訳にヒアリングが全然できてない。
とても耳が痛い内容でした。

『MixLeap Live LT #33 - 特別編「LTのはじめかた」』アーカイブ受講メモ #mixleap

勉強会

yahoo-osaka.connpass.com

2020/11/5 に行われたイベントの ライブ配信のアーカイブ が公開されたので視聴しました。
内容が素晴らしかったので、アーカイブから引用してメモしておきたいと思います。

LT のはじめかた

スピーカー：中嶋 道太郎

LT とは？

  • 短時間（約５分）のプレゼンのこと
  • ターゲット：LT に興味があるけどやったことない人
  • ゴール：LT をやらない理由が全て解決されること
    • やらない理由？
      • メリットがわからない
      • 話すネタがない
      • 資料を作るのが苦手
      • 死ぬほど緊張しそう

LT をやることのメリット

  • 伝えたい情報を聞く人がいて理解を得る行為は全てプレゼン
    • 商品の宣伝、自己紹介・面接、告白とか
      • 生きていく上で持っていると活用できるスキル
  • プレゼン力
    • 色々な能力が一気にあがる
      • 発想力、想像力、文章力、構成力、トーク力、度胸、デザイン力
  • アウトプットは楽しい！！

LT で話すネタの作りかた

  • 「話すネタがない」はない
    • 「話すネタがない」というネタがある
  • 「テーマ〇〇〇」について、やったことがない場合
    • 初めて〇〇〇をやった話が話せる
  • 料理が苦手 → 簡単な料理を初めてやったネタが作れる
  • 旅行が嫌い → 好きなことに置き換える
    • ゲームが好きなので「旅行している感があるゲーム」の話をする
  • 低レベルの話しかできない → 未経験者や超初心者向けの話をする
    • 発送を逆転させる
  • テーマは好きだけど面白く話せない
    • 「面白い話」がテーマじゃなければ別に好きに話せばいい
  • レベルの高い話、役に立つ話、面白い話などができなくても
    • 全く気にしなくて大丈夫！！
      • 自分が楽しめれば OK
      • 開催側は発表者がいるだけで嬉しい

良い感じの LT 資料の作りかた

  • 素敵な資料が作れない、しょぼい資料は恥ずかしい
    • まったく気にしなくて大丈夫！！
      • 「素敵なプレゼン資料」がテーマでなければ問題ない
    • LT 資料は好きに作って OK ！！
  • 文字は少なく大きくする
  • 絵や写真はたくさん使う

おすすめフリー素材サイト

イラスト
写真

良い感じのタイトル

  • 適当な背景画像
  • 黒の長方形、透明度60%
  • 白のタイトル文字

f:id:omron:20201124091028p:plain

良い感じのページ構成

  • 薄いグレーの背景 (#F2F2F2)
  • 好きな色の長方形
  • 白の見出し文字
  • 濃いグレーの本文文字 (#333333)
  • 良い感じのイラスト

f:id:omron:20201124091012p:plain

良い感じの見出しスライド

  • 好きな色の背景
  • 大きめの白文字

f:id:omron:20201124090956p:plain

まったく緊張しない方法

  • そんなものはない
  • 誰でも絶対に緊張はする！！
    • 和らげる方法はある
      • 準備と経験
  • 不安は準備で打ち消せる
    • 資料作り、台本、壁打ち
  • 経験はやればやるほど慣れる、楽しくなる
    • １回やってみる

まとめ

  • メリットが分からない
    • 人生の役に立つ、能力上がる、楽しい
  • 話すネタがない
    • どんなことでもネタになる！レベルも気にしなくて OK
  • 資料を作るのが苦手
    • 好きに作る！良い感じの資料の作り方も割と簡単
  • 死ぬほど緊張しそう
    • 誰でも緊張するので気にしない！準備と経験で軽減

所感

プレゼンなれしたデザイナーさんがまとめた素晴らしい資料とプレゼンです！！
自分のプレゼンは写真を使うことはなかったので、今後写真も交えたプレゼンを考えてみたいと思います。

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

AWS 勉強会

jawsug-asa.connpass.com

テレワークが続く限り参加できる朝会の日です。

セッション① AWS Organaizationと一緒にはじめるアカウント分離

講師：株式会社スナックミー 多田 貞剛さん

speakerdeck.com

  • 会社紹介
    • snaq.me
    • 新しいおやつ体験を想像し、おやつ時間の価値をあげる
  • AWS アカウント管理の課題
    • AWS 1アカウントのみ
      • ステージ、開発も同一アカウント
      • 開発中に本番触る事故
    • AWS リソースが手で作ったり、コード化されてたり管理バラバラ
    • ローカル Docker だと動くけど本番で動かない
      • Docker on Mac は動作するのに ECS だと動かないとか
      • インスタンスタイプが問題だった
    • 本番システム構成を変えづらい
    • AWS 管理が CTO のみ
      • 開発メンバー全体の習熟度アップ
  • AWS Organizations 使って解決したい！
    • Landing Zone の考え方を参考に進めている
      • Landing Zone はベストプラクティスに基づいたマルチアカウント環境のセットアップをサポートする仕組み
    • ステージングとサンドボックスに分割
    • リソース管理は IaC 化して対応
    • 利用料は redash で可視化
    • CloudTrail, Config, GuardDuty 設定
  • 今後やりたいこと
    • SSO 利用
      • GSuite を IdP にした SAML 認証
    • ログ集約アカウント
    • Organizations 活用したアカウント管理

セッション② AWSのこんなイケてないモノ

講師：運用設計ラボ合同会社 波田野 裕一さん

サービス名は Tweet 禁止とのことなのでまとめもできず。
資料なし、通勤中にも聞いたりできるようにラジオ風のセッションでした。

LT① JAWS DAYS 2021 開催のお知らせ

講師：榎本 航介さん

www.slideshare.net

  • JAWS DAYS 2021 を 2021/3/20 10:00 - 18:00（仮）で開催します
  • オンライン＋α
  • 12月にイベントサイト公開
  • JAWS SONIC 振り返り note も公開中

LT② Organizations周りの機能 2

講師：株式会社ターンアンドフロンティア 富松 広太さん

www.slideshare.net

  • 前回の朝会の続き
  • Organizations と連携可能なサービスを普通に利用するのと何が違うのか？
  • AWS Health
    • 単体で使う場合は Personal Health DashBoard で通知してくれる
    • 通常は EventBridge を子アカウントで設定して親アカウントへ通知が必要
    • 利用すると API で親から子アカウントに HealthEvent を一括設定可能になる
    • 子アカウントの HealthEvent を親アカウントから一括して取得できるようになる
  • AWS SSO
    • SSO 無しなら、親アカウントに IAM ログインして子アカウントに SwitchRole
    • SSO 有りなら、親アカウントへ SSO でログイン

所感

テレワークが続く限り参加しやすい時間なので朝会は助かります。
ただ、登壇する費とは大変だと思いますね...いつもありがとうございます。
終わったあとの雑談タイムも非常に楽しいので参加してみると面白い会だと思います。

「JAWS-UG CLI専門支部 #171R S3基礎 通知 (Lambdaの自動実行)」受講時の Cloud9 事前準備不足について調べた #jawsug_cli

勉強会 AWS

jawsug-cli.connpass.com

過去、JAWS-UG CLI専門支部のハンズオンは、最後までオンタイムで完走することができていました。
今回は量が多いこともあり、途中でうまく行かないとついていけなくなり、最後までオンタイムで進めきることができませんでした。
なぜ失敗したかを探りたいと思います。

過去のハンズオン作業環境

今まで受けてきた CLI 専門支部のハンズオンは、macOS のターミナルで処理をしていました。
aws コマンドは 公式資料を参考に Docker 上で起動して利用しております。

aliase aws='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

多少苦労する点はありましたが、だいたい時間内に完走はできておりました。
CLI 専門支部のハンズオンで推奨されている Cloud9 環境との違いをまとめます。

aws cli version の違い

「CLI のバージョンは新しいほうがいいだろう」ということで、ローカル環境では v2 を利用しております。

$ aws --version
aws-cli/2.0.43 Python/3.7.3 Linux/5.4.39-linuxkit docker/x86_64.amzn.2

一方、CLI 専門支部は v1 での動作保証をしている状況です。
バージョンは違いますが、ここが問題になることは過去ありませんでした。

BSD と GNU の違い

macOS 標準のターミナルのコマンドは、基本 BSD の sed や awk です。
一方、CLI 専門支部のコマンドは Amazon Linux2 になるため GNU のコマンドです。
それぞれのコマンドオプションなど違う場合があり、BSD 版に読み替えて書き直す必要がありました。
ハンズオンでは、遅れないように急いで書き換えて、なんとかついていくようにしてました。

今回のハンズオン作業環境

Cloud9 との出会い

CLI 専門支部では、Cloud9 を利用した環境を前提としております。
別のハンズオンで Cloud9 を利用したことがあり、一度 Cloud9 を使ってみるととても便利でした。

「Cloud9 使えば、今までみたいな苦労はなくなり余裕でついていける！」と考えて、今回のハンズオンからは Cloud9 の利用に切り替えました。

事前確認

私は aws コマンドが正しく動くかの確認をいつも aws s3 ls で行っております。
S3 バケットを見ればどの AWS 契約につないでいるかわかるため、事故を起こさないために必ず最初にこのコマンドを叩きます。
ハンズオン環境で利用しているバケットが見えたので、接続先は問題ないと確認できました。

また、ハンズオンで利用しているユーザーは Admin 権限で作っております。
Admin であれば Role 設定をいちいちしなくても困らないだろうと考えました。

問題が発生した

IAM 権限がない

Cloud9 上で作業を進めていると以下のエラーが発生しました。

$ aws iam create-group \
>   --group-name ${IAM_GROUP_NAME}
An error occurred (InvalidClientTokenId) when calling the CreateGroup operation: The security token included in the request is invalid

「あれ？ IAM の作成権限が足りてない？」ということで、ローカルからコマンドを叩いて乗り切りました。

S3 バケットへアップロードができない

今回作業に使うユーザーは、ローカルからコマンドを叩いて API キーを取得しました。
この情報を Cloud9 上に配置しました。
新たに作成したユーザー権限で動作するから、これ以降は問題出ないだろうと思いました。

しかしながら、S3 へのアップロードでエラーが発生してしまいました。

$ ${FILE_SCRIPT}   ${ARGUMENT_1} ${ARGUMENT_2}
upload failed: local-handson-cli-s3/handson-cli-s3-notification.txt to s3://handson-cli-s3-notification-686609377265/sample/0.tmp An error occurred (InvalidAccessKeyId) when calling the PutObject operation: The AWS Access Key Id you provided does not exist in our records.

今回作成したユーザーには権限が足りているはずですが、S3 へのアップロードができません。

API キーの書き換えができない

では、ローカルでも利用している Admin 権限のキーを .aws に配置すれば何でもできるだろうと思い配置してみました。
しかしながら、ワーニングが発生したので強制的に書き換えることはやめました。

f:id:omron:20201114171527p:plain

何が原因だったか？

Cloud9 環境の作り方が問題だったんだろうと考えました。
再度 Cloud9 を作り直して権限を増やそうとしましたが、デフォルトで設定されているロールから変更することはできません。

f:id:omron:20201114171842p:plain

CLI 専門支部のハンズオンの Cloud9 と何が違うのか調べることにしました。

AWS CLI利用環境(Cloud9)の構築・利用・破棄(簡易版)

prototype-handson-cli.s3-website-ap-northeast-1.amazonaws.com

「『GUI は中学生まで』の波多野さんの資料なのに GUI のキャプチャーが大量にある！ 」
ということにびっくりしながら、これにならい Cloud9 環境を構築していきました。

「Cloud9 を起動している EC2 のロール権限が無い！」

1.2. EC2インスタンスへのIAMロールのアタッチ (handson-cloud9-env)

順に進めていき、この項目に来たときに気が付きました...
Cloud9 を起動している EC2 から cli を叩くときは、EC2 自身の IAM ロールにも影響を受けます。
EC2 に IAM ロールが足りていなかったため、Cloud9 環境から叩けるコマンドに制限があったようでした。

まとめ

  • Cloud9 も EC2 で動いているのでアタッチされているロールに依存する
    • 権限がある API キーを利用しても制限を受けてしまう
  • ハンズオン環は手順に沿えば全く問題はない
    • 違う環境でやるのは自己責任
      • 勉強になるので違う環境も基本は楽しい
      • しかし、ハンズオンの量が多いときには辛い

理由がわかれば単純なことでした。
Cloud9 自体はとても便利なので今後も活用したいと思います。

（小ネタ） AWS RDS エンジンのスケジューリングアップデート

小ネタ AWS

AWS RDS のエンジンは、スケジューリングしてアップグレードすることができます。
メンテナンスの動作については、以下の3種類のボタンがあります。

f:id:omron:20201113082951p:plain

それぞれ何が起きるか理解しておかないと事故が起きてしまうので確認を行ないました。

  • 却下
    • アップグレードを実施しない
  • スケジュール
    • 次のメンテナンス期間に適用する
  • 今すぐ申し込む
    • すぐに適用する

という動作をするようです。
ボタンだけ見ると「今すぐ申し込む」が表記されたスケジュールでの実行で、「スケジュール」がスケジュールの変更かと勘違いしていました。

では、スケジュールを変更したい場合はどうするかというと、以下のドキュメントに記載があります。
Amazon AuroraDB クラスターのメンテナンス - Amazon Aurora

DB クラスターの適切なメンテナンスウィンドウを調整するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
  2. ナビゲーションペインで、[データベース] を選択します。
  3. メンテナンスウィンドウを変更する DB クラスターを選択します。
  4. [Modify] を選択します。
  5. [メンテナンス] セクションで、メンテナンスウィンドウを更新します。
  6. [Continue] を選択します。 確認ページで、変更内容を確認します。
  7. 変更をメンテナンスウィンドウにすぐに適用するには、[変更のスケジューリング] セクションで [今すぐ] を選択します。
  8. [クラスターの変更] を選択して､変更を保存します。 または、[Back] を選択して変更を編集するか、[Cancel] を選択して変更をキャンセルします。

ドキュメント記載の通り RDS クラスターの（ドキュメントだと [Modify] だけど、日本語コンソールの場合）[変更] から、スケジュール時間を変更して対応することができます。

f:id:omron:20201113085249p:plain

Aurora クラスターの更新には概ね 20〜30 秒のダウンタイムが発生する ので、メンテンナンス計画をちゃんとして対応しましょう。

「JAWS-UG 初心者支部 #33 大分支部コラボ!! amplify +AWS LT大会!! 」受講メモ #jawsug_bgnr

AWS 勉強会

jawsug-bgnr.connpass.com

Amplify 勉強中...聞くより触るほうが早いなーと思いながらも、まだそれほど使いこなせてません。

①20分 セッション & QA10分：Amplifyサービス概要と始め方

講師：AWSJ 亀田 治伸さん

大分出張の楽しみは このラーメン屋さん とのこと。
さっしーの親戚がやってるらしいけど、それと関係なく美味しいと。

  • Amplify = 増幅する、アンプと同じ語源
  • 今どきのWebアプリ
    • ユーザー間のチャット
    • プッシュ、レコメンド
  • アプリ開発者がやりたいことに集中できるように
  • Amplify は CI/CD も兼ねる
  • Cypress による E2E テストが統合済み
  • ホスティングと CDN による配信
  • 独自ドメインと SSL 証明書の設定
  • Amplify DataStore
    • GraphQL 経由で自動的にアプリとバックエンドのデータを同期
    • AWS AppSync と連携してデータを同期、コンフリクト解決
  • Amplify Console

Amplify の参考ハンズオンは こちら

②10分 LT & QA5分：多分みんなが思ってるよりAmplifyはずっとすごい

～ぼくとAmplifyの18ヶ月～

講師：浜松支部 松井 英俊さん

  • Amplify のことを発信してたら
  • Amplify 活用事例
  • Amplify いいところ
    • フロントエンドを爆速でデプロイできる
    • 認証がすごい楽
  • Amplify の勘所
    • ビルド設定（ Next.js 初期設定だと動かなかったり）
    • SPA でのリダイレクト設定
  • Apmlify とは
    • 爆速デプロイでいち早くアイデアを具現化して運命を変えるツール

③10分 LT & QA5分：AWSへ移行する！

〜だから勉強してねと言われた全国初学者の皆様に〜

講師：shiro-kujiraさん

  • 元公務員、工場、製造、重機好き
  • これから AWS を導入するらしい
    • すごいサービスなのはわかるけど
    • オンプレミスでもよくない？
    • モチベーションどうしよう
  • AWS の導入事例をみて成功イメージを
    • 大阪の金属加工業で導入事例を参考
    • 中小企業も導入している
  • 現在は社内にオンプレ10台
    • 5年に一度 1000万かけて入れ替え
    • IT 管理は課長一人
  • AWS 導入まで
    • 経営者セミナーきっかけ、5年かけて対応
  • 結果運用金額は AWS のほうが高い
    • 空調や場所は削減
    • 管理業務削減、管理維持コストは大幅減
  • この事例をみて会社の未来を想像して AWS 学習 !

④5分 LT：IAMのロールで本番環境を守る！

講師：齋藤玄さん

  • スマホアプリの開発
    • 一人で作っている
  • 本番環境を間違えて変更したトラブル発生
    • IAM ロールで管理して対策
  • 普段は開発環境しか見えない
    • ロール切り替えで本番が見えるように
  • ポイント
    • ロール設定を厳しくすると開発しづらい
    • いい塩梅が必要、先輩に聞く
    • リリース前にやるべきだった
  • 開発環境の整えは地味だが派手なミスを防げる！

⑤5分 LT：Amplify CLIが作成するバックエンド

講師：初心者支部 山原 崇史さん

speakerdeck.com

  • Amplify って何なん？
    • Amplify での構築イメージがつかめない
  • Amplify のチュートリアルにトライ
  • Amplify とは？
    • フロントからインフラとデプロイまで1人でできる人は少ない
    • 分業となるとコミュニケーションコストのオーバーヘッドもある
    • これらをフロントエンドエンジニア1人で完結できる Amplify は強力
      • 高速で MVP を作れる

所感

できることが多い上、コンソールやら CLI やらなんやら種類も多いから余計に混乱しがちなサービスです。

という認識です。
インフラエンジニアとしては、CLI やコンソールを使って楽にバックエンドを構築できるサービスと思っています。
こんな理解であってるんかな。もっと使いこなさないと。