omuronの備忘録

個人的な備忘録

「ssm start-session コマンドを楽にする」をやってみた #AWSStartup

aws-startup-community.connpass.com

先日受講した「AWS Startup Tech Meetup Online #3」にて、ssm start-session を楽にするというのを紹介していたのでやってみました。

やってみる

macOS 10.15 のターミナル( zsh )で試してみます。

peco インストール

brew で楽にインストール。

brew install peco  

EC2 情報取得

ec2 describe-instances を利用して、「インスタンス ID」「名前」「プライベートIP」を取得する。

aws ec2 describe-instances --output text --query "Reservations[].Instances[].[InstanceId,KeyName,PrivateIpAddress]" 
i-0000000000000000  name1   172.31.30.76
i-9999999999999999  name2   172.31.21.225

追記
(Tags[?Key=='Name'].Value)[0] も、クエリに入れると名前が見えて良さそう。

peco で選択

peco をパイプでつなぐ。

aws ec2 describe-instances --output text --query "Reservations[].Instances[].[InstanceId,KeyName,PrivateIpAddress]"  | peco
QUERY>                                                      IgnoreCase [2 (1/1)]
i-0000000000000000  name1   172.31.30.76
i-9999999999999999  name2   172.31.21.225

選択したインスタンス ID を取得

awk で、 peco で選択したインスタンス ID だけを取得する。

aws ec2 describe-instances --output text --query "Reservations[].Instances[].[InstanceId,KeyName,PrivateIpAddress]"  | peco | awk '{print $1}'`
i-0000000000000000

SSM で接続

aws ssm start-sessiontarget に渡して、SSM で接続する。

aws ssm start-session --target `aws ec2 describe-instances --output text --query "Reservations[].Instances[].[InstanceId,KeyName,PrivateIpAddress]" | peco | awk '{print $1}'`

Starting session with SessionId: botocore-session-9999999-999999999999

いけました。
あとはこれを aliase にするなり、 function にするなりすれば使いまわせそうです。

セッション資料

かんたんコンテナロギング選手権

speakerdeck.com

AWS Systems Manager で実現する、 SSH レスでセキュアなクラウド運用

speakerdeck.com

AWSエンジニア特化のマッチングプラットフォームを開発した話

speakerdeck.com

セッションアーカイブ

youtu.be

所感

Kyash はお金を扱っているだけにセキュリティにはかなり気を使っているのがわかりました。
決済会社とはそれぞれ Direct Connect したりしてるんですね。
センシティブな情報も多くログの管理や、SSM の利用方法など参考になる情報が多く勉強になりました。

ターン・アンド・フロンティア「AWS大阪リージョン活用法」 受講メモ

aws.taf-jp.com

株式会社ターン・アンド・フロンティアのイベントです。
中山はるなさんが執行役員になってたのに驚いて申し込んでしまいました。

前座で今日のイベントの参加者の地域を聞いてました。

場所
大阪 61%
大阪以外の関西圏 14%
東京 11%
その他 14%

やっぱり関西強いですね。

これだけは知っておきたい「新しい大阪リージョンの基本情報」

講師:エンジニア 坂下 朱紀氏

大阪に縁もゆかりもないエンジニアさんとのことです。

大阪リージョンについて

  • 2018/2/13 大阪ローカルリージョン先行サービス開始
  • 2021/3/2 開設、東京リージョンからちょうど10年
    • フルリージョン化、3AZ
  • 東京リージョンとの違い
    • サービス数が少なく 56、東京は 169
    • EC2、コンテナ系は普通に使える
    • RDS:Neptune 使えない
    • ネットワーク:Client VPN 使えない
      • VPN のコンソール画面のメニューが少ない
    • ストレージ:FSx, Storage Gateway 使えない
    • アプリケーション:MQ 使えない
    • エンドユーザーコンピュート:全部使えない
    • マネジメント:OpsWorks 使えない
    • セキュリティ系:Directory Service, GuardDuty, WAF 使えない
    • 分析:Athena, QuickSight, Kinesis Video Streams, Kinesis Data Analytics 使えない
    • 開発:CodeDeploy 以外は使えない

DR について

  • バックアップとリストア
    • S3 を大阪にレプリカ、障害時に S3 からリストア
    • 障害時に EC2 だけ起動し直す
  • パイロットライト
  • ウォームスタンバイ
    • 低スペックで EC2/RDS を準備
    • 障害時に Route53 で向きを変える
  • マルチサイト(ホットスタンバイ)
    • 同じものを準備
    • 障害時に Route53 で向きを変える

まとめ

  • 選択の幅が増えた
  • 使用できないサービスに注意
  • 国内で DR ができるようになった

「実際に大阪リージョンにサーバを立ててみよう!」

講師:エンジニア 西橋 奈央氏

リトルマーメードのウツボが好きだそうです。

EC2 インスタンス構築実演

  • 第6世代の Arm がない、x64 のみ
    • ボリュームは gp3 にすると最低 IOPS が 3,000 からになる

レイテンシー検証

大阪リージョン

$ ping 13.208.137.92
PING 13.208.137.92 (13.208.137.92): 56 data bytes
64 bytes from 13.208.137.92: icmp_seq=0 ttl=242 time=32.402 ms
64 bytes from 13.208.137.92: icmp_seq=1 ttl=242 time=13.770 ms
64 bytes from 13.208.137.92: icmp_seq=2 ttl=242 time=10.109 ms
64 bytes from 13.208.137.92: icmp_seq=3 ttl=242 time=20.020 ms
64 bytes from 13.208.137.92: icmp_seq=4 ttl=242 time=16.969 ms
^C
--- 13.208.137.92 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.109/18.654/32.402/7.623 ms

東京リージョン

$ ping 54.250.61.180
PING 54.250.61.180 (54.250.61.180): 56 data bytes
64 bytes from 54.250.61.180: icmp_seq=0 ttl=237 time=41.917 ms
64 bytes from 54.250.61.180: icmp_seq=1 ttl=237 time=13.773 ms
64 bytes from 54.250.61.180: icmp_seq=2 ttl=237 time=26.167 ms
64 bytes from 54.250.61.180: icmp_seq=3 ttl=237 time=36.670 ms
64 bytes from 54.250.61.180: icmp_seq=4 ttl=237 time=24.189 ms
^C
--- 54.250.61.180 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.773/28.543/41.917/9.876 ms

バージニア北部リージョン

$ ping 107.22.41.82
PING 107.22.41.82 (107.22.41.82): 56 data bytes
64 bytes from 107.22.41.82: icmp_seq=0 ttl=235 time=190.713 ms
64 bytes from 107.22.41.82: icmp_seq=1 ttl=235 time=193.564 ms
64 bytes from 107.22.41.82: icmp_seq=2 ttl=235 time=200.965 ms
64 bytes from 107.22.41.82: icmp_seq=3 ttl=235 time=204.297 ms
64 bytes from 107.22.41.82: icmp_seq=4 ttl=235 time=223.886 ms
^C
--- 107.22.41.82 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 190.713/202.685/223.886/11.675 ms

兵庫県からの検証してみました。

  • ping は大阪少し速い
    • 大阪: 18.6msec
    • 東京: 28.5msec
    • 米国:202.6msec
  • http は東京大阪あまり変わらず、米国は少し遅い

「大阪リージョンのはじめ方」

講師:執行役員 中山 晴菜氏

  • 新しいシステムを構築
    • 構築時に大阪リージョンを使うだけ
    • 一部機能なし
    • VPC ピアリングで東京とつないで補う
  • 東京リージョンから引っ越し
    • EC2 であれば
      • AMI 作成、リージョン間コピー、コピーから起動
      • 注意点
        • 停止時間が発生する
        • EIP 取り直し
        • DNS の切替対応
        • サービスによっては作り直し
  • 東京リージョンとの DR
    • どのような DR 構成をとるか?(最初の説明のどれにあたる?)
    • RTO, RPO, コストを天秤にかける
    • BCP 訓練はしたほうが良い
  • どのケースでもテスト検証はしっかりしましょう

所感

いまさらチャンネル で見ることはありましたが、久しぶりに Live ではるなさんの講演を見ましたが相変わらずおしゃべり上手でした。
チャンネル登録者2万5千人近くですごい。
いろいろ強い方なので執行役員になるのもうなずけます。

大阪リージョンは軽く触って、セキュリティ系が弱い(GuardDuty が無い)辺りが痛いかなーと思ってましたが DR 対策に使うには十分な感じですね。
普段使わないサービスも含めて利用できないサービスを知ることができたのが良かったです。
ただ、この使えないサービスは明日には変わっている可能性もあるのが AWS のいいところでもあり怖いところでもあります。
エンドユーザーの多い東京リージョンをメインで使うことは続きそうですが、大阪も普通に選択肢に入るので、上手いこと使い分けて行きたいと思います。

ecspresso を試してみる

OSS な ECS デプロイツール ecspresso に Deep Dive!」 を受講

omuron.hateblo.jp

ecspresso の概要がわかったので、動作を確認してみます。
動かしてみて、勉強会で聞いたときに想像したのと違うところの備忘録。

動かしてみた

IAM ユーザー作成

CLI を呼び出す用の IAM ユーザーを CloudFormation で作成。
MFA を設定すると AssumeRoleTokenProviderNotSetError がでて、回避方法がわからなかったので、MFA はなし。
この IAM ユーザーの API キーを発行して試していく。

AWSTemplateFormatVersion: 2010-09-09
Description: IAM

Resources:
  IamUserDevECS:
    Type: AWS::IAM::User
    Properties:
      UserName: devecs
      Policies:
      - PolicyName: DevECS
        PolicyDocument:
          Version: '2012-10-17'
          Statement:
          - Effect: Allow
            Action:
              - ecs:*
              - ecr:*
              - iam:PassRole
            Resource: '*'
    DeletionPolicy: Delete

init

$ ecspresso --config config.yaml init --cluster ecspresso-demo --service nginx-service

--config config.yaml の設定も必要。
init 時には、ここで設定したファイルに config 情報が出力される。
ゆえにこの時点では予め config.yaml ファイルを事前に準備しておく必要はない。

diff

$ ecspresso --config config.yaml diff

すべての差分がでるわけではない。
"desiredCount": 1, のタスク数などは対象外だったりする。

deploy --task

zenn.dev

タスク数は deploy 時に引数で指定できる。
指定しない場合は、(差分としては表示されないが)ecs-service-def.jsondesiredCount の値が反映される。

deploy --force-new-deployment

強制的にタスクを入れ替えるなら以下のコマンドで可能。

$ ecspresso --config config.yaml deploy --force-new-deployment

refresh コマンドが準備されているのでこちらのほうが適切と思われる。

zenn.dev

verify

依存する各種リソースが利用可能かは verify コマンドで検証できる。

$ ecspresso --config config.yaml verify

zenn.dev

このコマンドを利用する場合は、IAM 権限にログやロードバランサーへのアクセスも必要になるので、以下も許可する。

              - logs:*
              - elasticloadbalancing:DescribeTargetGroups
              - iam:GetRole

所感

まだ簡単にしか触ってませんが、CFn や CLI でやるよりも理解しやすく、 アドベントカレンダー にヒントもあるからとてもわかりやすいです。
もう少し使いこなせるように試していきたいと思います。

「DevLead by DMM Group #3 〜評価制度・育成編(エンジニア・デザイナー)〜」 #devlead_dmm 受講メモ

dmm.connpass.com

最近は組織のことも考える必要があるため、気になるところだけメモしました。

セッション

DMMのLC事業部 開発部門における育成と評価について

講師:紙谷 勉氏

  • 失敗を許容、小さく多く施策を打てる開発目指す
  • 部員
    • エンジニアリングマネージャー
      • 組織活性化の意図を構築する
    • グループリーダー
      • ミッションの背後の何故を浸透
    • チームリーダー
      • 具体化させる「どうやって」を遂行 なにをどうやっていつまでに
    • 開発メンバー
      • 具体化させる「どうやって」を遂行 どうやっていつまでに
  • 期初コミュニケーション
    • will/Can の言語化
    • will/Can のギャップ
    • 組織目標からブレイクダウン
  • 期中コミュニケーション
    • 1on1
  • 期末コミュニケーション
    • 評価面談、起案、すりあわせ、評価、フィードバック
    • 育成のためのフィードバック
      • フィードバックがないと人事評価だけになる
      • 強み、持ち味、悪いことも解決できる課題として伝える

DMMエンジニアリングマネージャーの1年間と考えていること

講師:梅林 良太氏

  • 成果を出している人にちゃんと報いる
    • 報酬だけじゃなくて機会(チャンス)も
  • 相対評価
    • 市場原理、価値(希少性)
  • マネージャー
    • 組織として成果
    • マネジメント:適切に配分、俯瞰し支援
    • リーダーシップ:方向性を示す、要所で矢面に立つ、率先し誘導
  • 制度・ルール・システムを無機質に扱わなず人と向き合う

意欲と能力を高める"仕掛けづくり"への挑戦

講師:安倍 仁士氏

  • 人事制度:目標達成評価 x 行動評価
  • スキル習得状況の可視化、オンライン学習フォロー
  • OKR運用の win session 導入
  • メンタリング施策でテレワーク環境でも関係構築
  • 非開発者向けの開発基礎教育:非エンジニアへ SQL 学習展開
    • 非エンジニアもデータドリブンな意思決定を
    • 開発職とのコラボレーション
  • スキルコンバート:他職種からエンジニアへ

所感

組織を成長させるっていうのは、自分だけの力ではどうにもならないから先人に学ぶことは大事と思います。
評価育成を語ってもらえて、聞くことができるのは貴重な機会でした。

言語化能力高い...
評価や育成するためにはまず言語化能力上げることも大事と改めて思い知らされました。

「OSS な ECS デプロイツール ecspresso に Deep Dive!」 #ContainersFromTheCouch 受講メモ

OSS な ECS デプロイツール ecspresso に Deep Dive!

aws-container.connpass.com

github.com

brew でインストール可能。

$ brew install kayac/tap/ecspresso

デモ

$ ecspresso --config config.yaml deploy

ecs-service-def.json, and ecs-task-def.json を作ってデプロイ。

$ ecspresso --config config.yaml diff

diff で AWS とローカル設定の差分を見れる。

$ ecspresso --config config.yaml rollback

で一つ前の定義に戻せる。

なぜ作った?

  • cliシェルスクリプトで作ったけどやりたいことがいろいろあったのでツール化した
    • 他のツール(Ruby)とかもあったけど慣れてる言語でやりなおした

特徴的な機能

  • ECS 側の状態をファイル化することができる
$ ecspresso --config config.yaml init --cluster ecspresso-demo --service nginx-service
  • マネコンの状態を引っ張ってファイル(config.yml, ecs-service-def.json, and ecs-task-def.json)にダンプできる
    • マネコンとか他のツールで作成した ECS を ecspresso の管理ファイルにジェネレート可能
    • カヤックは Terraform で初期構築
  • ECS しか触らないので、それ以外には影響はない

CloudFormation 連携機能

  • CFn でアウトプットした情報を参照可能
    • plugin で設定
  • VPC とか SG を CFn でその値を取り込んだりできる

環境ごとに設定を変えたい

  • タスク定義の environment で可能
    • テンプレートになっている
    • 環境変数に設定して読み込ませる
      • LOG_LEVEL=info ecspresso --config config.yaml diff
      • must_env にしておけば実行時に指定しなければ即死ぬようになっている
      • デフォルト値を使いたい場合は must_env を消して初期値を yaml に記載する

作者お気に入りの機能

  • 最初 ECS がデプロイできてもなかなか起動しないケース
    • Imageがない、ロググループがない、IAMがない、LBがない...などなど
      • マネコンだとロググループ勝手にできるけど CLI だと作られない
    • verify コマンドでチェックできる
      • dry-run もあるけど守備範囲は違う
  • scale 台数(タスク数)を変えたいとき
    • deploy コマンドでもできるけど事故が発生しがちなので作った
  • refresh 設定を変えないで新しいタスクに入れ替える
    • Fargate の基盤の更新時にタスクを入れ変えたいときになど利用
  • run スタンドアローンなコンテナを一発動かしたいとき
    • --overrides でタスク定義を上書きして実行

新機能

sfujiwara.hatenablog.com

スケジューリングしたい

github.com

  • ecschedule を推奨
    • dump して ecspresso と同じような感覚(inspired by ecspresso.)で利用ができる

これから始める人向けのドキュメント

アドベントカレンダー を本にまとめ直して販売中。
https://zenn.dev/fujiwara/books/ecspresso-handbook

所感

ECS 使いたくて CloudFormation で書いてたけど本当に辛くて、AWS の SA さんに相談したところ「CDK か ecspresso がおすすめ」と言われました。
CDK で実装したところ CFn に比べて非常に簡単で ecspresso は手を付けてない状態でした。
ecspresso を利用すれば、CDK で初期構築したタスクを簡単に変更ができそうなことがわかりましたので、今後運用では活用してみたいと思います。

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

jawsug-asa.connpass.com

最近少し暖かくなってましたが、今日は寒い朝でした。

セッション① AWS KMSを触る

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

www.slideshare.net

  • AWS KMS 概要
    • 鍵を安全に補完
    • AWSサービスのデータ暗号化復号化と連携
      • S3, EBS
    • セキュリティのポイントを自動化
      • キーローテーション、暗号化鍵の方式
  • CMK とデーターキーの違い
    • データーキー : データーを暗号復号化するために利用
    • CMK : データーキーを暗号復号化するために利用
      • Customer Master Key を AWS 外部に出したくないから
      • データを AWS に送るのは不便
  • エンベローブ暗号化
    • 暗号化対象のデータ量が一定
  • 使い方
    • aws kms create-key : 鍵を作って
    • aws kms create-alias : 扱いやすくするためエイリアス付けて
    • aws kms generate-data-key : 使い捨ての鍵を生成して利用
  • EC2 に EBS アタッチ時に KMS を利用した場合
    • KMS を削除すると再アタッチできなくなる
      • 間違って消したときは EC2 起動中にデータをコピー
  • CMK
    • AWS owned CMK : AWS が管理、見れない
    • AWS managed CMK : AWS が管理、見れる。aws/service-name 形式
    • Customer managed CMK : 利用者が管理
      • aws が作成
      • 自分で作成
    • データキー:データの暗号/復号に利用
  • KMS ローテーション
    • Backing key というキーの実態を自動で入れ替えしてくれる
    • key-ID やエイリアスはそのまま利用可能
      • 利用者への影響はない
    • 暗号化時に使った backing key の ID をヘッダーに含んでいる
      • ローテーションしても過去のキーを自動で利用する仕組み
  • KMS 削除
    • 削除は慎重に、復号化できなくなる可能性あり
    • ScheduleKeyDeletion で一定期間様子見、利用時に通知可能

セッション② Amazon QuickSight導入事例で解説、お蔵入りしないBI導入のポイント

株式会社アイディーエス 小寺 加奈子さん

www.slideshare.net

  • データ活用プロジェクトがお蔵入りするのはなぜ?
    • データをみて感想がでるだけ
      • で、どうする?
    • データが違う
      • 反映が遅い
    • データを出すのに時間がかかる
      • カスタマイズ対応と費用
  • 失敗パターン
    • 目的がそもそも不明確
    • BIをアップデートしない
    • 定量的に評価改善できない
    • BIツールを使えない
  • データーソース -> 収集 -> 加工 -> 蓄積 -> 最適化 -> 可視化
    • 加工でのデータクレンジングが必要
  • まとめ
    • 作って終わりではない
    • PDCA を回し続ける業務プロセスと実行可能な体制の構築
    • データ活用 -> データドリブンな組織へ

データを活用する組織の風土/文化作りが本当に大切だと思うだけど、成功体験もたせてこの風土/文化を作るのが大変ですよね。
BIって使わなくても業務が回るだけに、協力者の確保と継続が本当に難しいと思います。

セッション③ AWS関連のブログを書いてて山ほど得したこと報告

トレノケート株式会社 山下 光洋さん

www.slideshare.net

そもそも手を動かしている量がすごいです。
まずはインプットをしないとアウトプットすることもないので、探求心と行動力が大事ですね。
とりあえず見えるところにメモを出している身としては、「取ってるメモを見えるところにおくかどうかだけ」というのはそのとおりだと思ってます。

所感

今日は理解しにくい AWS KMS の話から、導入後に死にがちな BI ツールのお話、最後はアウトプットの心得まで幅広い内容でとてもよかったです。
データドリブンかつアウトプットできる組織を作っていきたいですが、本当に難易度が高い。
登壇もそろそろしたいので自分もチャレンジを続けていきたいと思います。

「Serverless Meetup Japan Virtual #16」 #serverlessjp 受講メモ

Serverless Meetup Japan Virtual はほぼ毎回見ているのですがメモを取ったのは久しぶりです。

serverless.connpass.com

ハッシュタグ#serverlessjp
今日の動画のアーカイブ

技術選定でサーバーレスを採用した話

講師:コロニー株式会社 座安 勇貴氏

APIG + Lambda + RDS (Service APIs)

  • フロントエンド: Amplify(Angular, TypeScript)
  • バックエンド: APIG + Lambda
    • RDS Proxy + RDS
    • Cognito
    • DynamoDB
  • Lambda タイムアウト問題
    • Private Subnet の片方に NAT I/F の設定が漏れていた

Appsync + DynamoDB (Chat Functions)

  • フロントエンド: Amplify (GraphQL)
  • バックエンド: AppSync
    • Pipeline Resolver
      • DynamoDB -- Trigger --> Lambda
  • VTL はつらい
  • Lambda トリガー
    • メッセージの書き込みで発火処理実装可能

Cognito + Lambda + SES (カスタム認証機能)

  • Cognito のカスタム認証トリガーで Lambda を発火
    • 自前でランダムコードを生成して SES で送信
    • 認証チャレンジの検証
  • ググると出てくるので小さく簡単に実装できた
    • セキュリティ要件次第で将来拡張可能

S3 + RDS (Hosting File Service)

  • アップロード時に RDS にメタ情報など追加
    • S3 の署名URLを作ってオブジェクトアップロード
  • ダウンロードリクエスト時に署名URLを返却
  • 署名URL便利
  • ファイル名にマルチバイト文字を含むとダウンロードできない
    • Content-Dispositionヘッダーのattachmentでファイル名を指定していた
    • Content-Dispositionヘッダーのマルチバイト文字はエンコードが必要

まとめ

  • 細かいところでハマるけどサーバーレスは便利
    • アンチパターンに気をつける
    • 機能を小さくコード化できるのでノウハウを定型化しやすい
    • 複雑な機能軍を短期間で小さく開発できる、ビジネスに有利
  • 課題
    • API 以外のリソーステストの自動化
    • スケール対応
    • AWS の制限

所感

お手本のような構成+モダンな構成も取り入れた、今どきのサーバーレス環境を作っていると感じました。
スケール対応はサーバーレスだと得意分野とは思ったのですが

AWS の制限」は気にしておく必要がありそうです。

基本今から AWS を使う場合は「機能を小さくコード化できるのでノウハウを定型化しやすい」サーバーレスで実装できるかをまず考えるべきですね。