omuronの備忘録

個人的な備忘録

「JAWS-UG朝会 #11」手抜きアウトプット #jawsug_asa

朝会は起きれるか心配したけど、アラフォーには無駄な心配でした。余裕で起きてた。
朝会なのに 100 人超えの参加者はすごい。

jawsug-asa.connpass.com

ラジオ体操

「1級ラジオ体操指導士」なるものがあるのか。

ラジオ体操等の優れた技能と指導力を持って従来から継続的に普及推進活動に当たり、多方面にわたる活動を行いかつ高い実績を有し、原則として全国地域を対象に普及推進活動ができる者

セッション① public sector summitやオンライングローバルイベントへの招待(セキュリティ多め)

資料の リンク

グローバルなカンファレンスもオンラインになっていて無料で見れるものがたくさんある

  • アウトプットしないのは知的な便秘
    • アウトプットを決めておく
    • Twitter が難しいなら同僚に話すでもアウトプット
    • アウトプットは手抜きでもいい

手抜きアウトプットでもやらないより全然いいと思ってるし、備忘録になるし、小綺麗に頑張るとしんどくなるから、めっちゃ共感できる。

セッション② 久しぶりにAWS認定資格にチャレンジして良かったこと(仮)

  • 認定試験の受験環境が増えた
    • 地方都市でも受けれる
    • オンラインでも可能に
  • 認定試験の本が増えた
    • SAP や セキュリティスペシャリストの本も出た
  • 無料のデジタルトレーニン
    • 日本語字幕がされてたりもする
  • 定番の BlackBelt
    • YouTube で検索でも出たりする

自宅受験は環境を整える準備が大変そうな印象です。
受験会場近いならソッチのほうが楽そう。

LT① Amplify API (GraphQL) が簡単すぎて泣けてくる

speakerdeck.com

  • AWS AppSync をフロントエンドから簡単に使える

GraphQL やりたい詐欺で全然手を出せてない。
Amplify なんもわからん...

LT② 簡単!AmazonConnectでモーニングコール!!

speakerdeck.com

  • 起きれないを前提としたLT
    • 二度寝のために複数回目覚ましをする
  • モーニングコール作ろう
  • Amazon Connect
    • API で電話発信できる
    • モーニングコール自動化可能
    • 時間になったら電話くる
      • EventBridge から発信...だけだとつまらない
  • 何度もかかってくるようにしたい
    • 切っても何度もかかってくるようにした
    • 別のイベントで止めるようにしたい
      • Soracom ボタンで止める
  • アーキテクチャ
    • Amazon Connect
    • Lambda
    • SSM
    • EventBridge
    • IoT Button (SORACOM)

冒頭にも書いたけど、無駄に目が覚めるので作ることはないかなw

LT③ Honeycode

speakerdeck.com

  • チーム作業を効率化するサービス
    • まだβ版
  • 社内20人程度なクローズドな環境向け
  • 大規模には向いてない
  • プログラム経験がなくてもできる
    • ただ、エクセル関数を知ってるほうが強い
  • エクセルで管理してた業務などが対象
    • 存在しない場合もテーブル化しないとだめ
  • Lambda -> Honeycode はできるけど、Honeycode からはできない

所感

やらないアウトプットよりやる手抜きアウトプット。

「サーバーレスアンチパターン今昔物語 第2夜」受講メモ #serverless_newworld

サーバーレスアンチパターン今昔物語 第2夜 です。 第1夜はメモらなかったのが悔やまれる。

サーバーレスアンチパターン今昔物語 第2夜 - connpass

https://www.youtube.com/watch?v=ENs82QzJSsg

いきなり利用規約違反で再配信からスタート。

説明ブログ

今回の内容のブログ

www.keisuke69.net

以下、自分メモ。

Lambda 特性の前提について

コールドスタートをいかに短くするかが基本でそのお話のメモ。

定期実行で Lambda を起こすのは、昔からよくやるテクニック。
しかし、同時に定期実行した数だけしかウォームスタートされない のでおすすめしない。 (5分1回なら、1個のコンテナしかウォームスタートしないそうです。知らなかった。)

バースト制限はデフォルト 1,000 。
理由があれば緩和申請できるけど、最初は 1,000 しか起動しない。 1分毎に 500 コンテナずつ起動されてく。 東京リージョンは、1,000 だけど 2,000 だったり 500 だったりリージョンごとに違う。

Provisioned Concurrency について

リージョンごとに設定。
リージョンのデフォルトの起動数上限 -100 まで申請可能。
バースト特性と同じ用に、1分毎に増えていくので注意。

つまり、東京リージョンであれば一度に1,000をコールドスタートして初期化した後、1分ごとに500ずつ設定された値までプロビジョニングされていく感じ

ウォームスタートになるため、コールドスタート分のレイテンシ増を防げるという1点だけが利点。 ゆえに、コールドスタートが遅い場合にも有効。
ただし、お金がもちろんかかります。

まとめ

コールドスタートをお金で解決する手段。
同期処理を見直したりして、コールドスタートを早くするチューニングが基本。

Q&A

気になる回答だけメモ。

https://app.sli.do/event/vanvzgkx/live/questions

Lambdaからパスワード情報等を取得するベストプラクティスはどれになりますでしょうか?私はSSM ParameterStoreから取得し、オンメモリにキャッシュしてますが、パスワード更新時にどうlambdaに伝えようとか、キャッシュしない方が良いのかとか悩んでます、、

キャッシュするのは良い。シークレットマネージャーとかはライブラリが AWS から提供されているので利用スべき。更新時はキャッシュされた値でエラーになるだろうから、リトライでキャッシュ更新すればいい。

RDS Proxyの登場でLambdaからRDSへWriteの接続はアンチパターンじゃなくなったかと思うのですが、Readについては既存のままだと思うので結局アンチパターンになりうるのかなと思いましたが、その辺りのご意見伺いたいです。

Read は Write よりスケールアウトしやすいので、アンチパターンになりにくく扱いやすい。

Lambdaもローンチから長いこと経っているのでハードウェアも何世代かあるのではないかと思っているのですが、同じメモリ設定でもどのハードウェアで立ち上がるかによって、CPUパワーやネットワーク速度などに違いが出たりするんでしょうか?あるいは当たり外れが無いように調整されているんでしょうか?

答えれないので自信の目で確かめてください。Lambda Function から CPU Info 覗いたりしたら見えるだろう。

Lambdaのコード開発やテスト手法のベストプラクティスについてお伺いしたいです。

いろいろあるので具体的に言って欲しいので、次回フォーカスして話す。

日本のSIerだと、要件定義書、基本設計書、詳細設計書、単体テスト仕様書とエビデンス貼り付け、結合テスト仕様書とエビデンス貼り付け、システムテスト設計書とエビデンス貼り付けというようなドキュメントを作ると思います。AWSのサービス(Lambda自体とか)を開発するときはどういうドキュメントが残されますか?

知ってる範囲ではない。 自社サービス企業では、いわゆるドキュメントを残すのは少ないと個人的には思う。 納品のための成果物というイメージ。 デザインに関するドキュメントなどはあるが設計書などはカジュアル。

社外にメールでファイル添付するときどうやってますか?よくパスワード付きzipで送って、別メールでパスワード送るという方法があり、それならパスワードなしでそのまま送っても同じではと思っています。

パスワード付き云々はやらない。

AWSに入社するには対面での会議に問題なく参加できるレベルの英語力は必須ですか?

ポジションによる。読み書きは必要。必要以上に恐れなくていい。

海外の情報はどうやってキャッチアップされていますか?以前勉強会(well-architected)で海外のツールを紹介されていたりしたので、そういうツールなどを探す時にどうされているのか知りたいです。

特別なことはしていない。 普通にググったりするだけ。 英語のソースをみるケースは多い。 社内の人がグローバルなので、日本以外の人に聞くことはある。

Amazon SNS を削除する時に入力する「これを削除」が気になってしょうがないんですがどうにかなりませんか?というか他サービスに関しても削除対象のリソース名を入れないとあまり意味がないと思うんですが、この辺り方針は決まっていないんですか?

サービスによって統一されてないのでフォードバックありがとうという感じです。

Cloudformationのスタックはどの粒度で切れば良いでしょうか?Lambda function単位でしょうか?

ライフサイクルが同じ範囲でまとめるのがいい。 デプロイ、アプリケーションの更新などが同じもの。

CodePipelineからS3にWebコンテンツをコピーするとき、SyncじゃなくてCopyっぽいのですが、いい感じの方法はないですか。(今はCodePipelineからLambdaを呼んでSyncしています)

社内に聞いてわかれば Twitter で回答。

Lambdaをローカルで動かす sam local start apiを使って実行したポートにSPAのアプリからリクエストを送って動かすと、authorization をはじくというかdockerで動くLambda側で取得できない、またCORSに対応していないです。どう対応されてますか? postman等使う?

E2E でテストするならデプロイするのはどう?

Lambda、色々なランタイムが使えるようになっていますが、オススメのランタイムはどれですかね。周りに聞くと、Pythonって声が多いんですが(自分は普段はNode.jsメインです。時々Python)。

特におすすめはない。 Python はバランスがよく、コールドスタートに対するケアや速度も含めていい。 Java の人にも読みやすい。Node.js はちょっと癖がある。

Provisioned ConcurrencyはSQSは対応されないのでしょうか、、、これは将来的にもそうなのでしょうか。

ロードマップは答えれない。

Cognito User Pools のLambda トリガーなど、実行時間が伸ばせない場合では、バーストなどがなくてもProvisioned Concurrencyを設定することは有効ですか?

いろんなユースケースがあるので一概には言えない。

Lambdaの同時実行数バーストは、Lambda@Edgeでも同様ですか?(リージョンごとに制限されている同時実行数と同じ考えという理解です。)

後ほど Twitter で回答。

provisioned concurrencyのトラブルシュート方法はありますか? AWSブログはありましたがもし他にもあれば https://aws.amazon.com/jp/blogs/compute/investigating-spikes-in-aws-lambda-function-concurrency/

基本ブログ見てください。

Chaliceだと、1Lambdaに複数処理を追加できてしまいますが、モノリシックガチになるとすると、あまり進められない形でしょうか?

見解は分かれる。 程度問題と思う。 少なくとも全てをファットなファンクションにするのはやめたほうがいい。

秒間1000リクエスト以上来るようなAPIではLamdba使わないほうがいいでしょうか?

今日の話の通り、必ずしもそうではない。

以前Lambdaのランタイムのオススメ順が 1. Python 2. Go 3. Node.js というツイートをされていたと思いますが、その理由を伺いたいです。

1番目は Python だけど2番めは特に無い。 Node.js のメリットは Lambda ではあまり活かせないのでおすすめしない。

今日の内容とは関係ないですが、LambdaからDynamoDBDataMapper経由でDynamoDBの操作って可能ですか?ローカル環境では出来たのですが、実際にAWSにデプロイしたらInvalidSignatureExceptionで出来なかったので・・・ (edited)

サポートに問い合わせください。

AWSのSAから例えばテクニカルトレーナーになったりAmazonに行ったりとか社内の異動は頻繁ですか?

あるけど、自分が望んで移動するケースがほとんど。

普段、設計書の作成にはどのようなツールを使われてますか?私の会社では実質エクセルやパワポしか使えないのですが、図はdraw.ioを利用してます。

社内 Wiki だったり、社内ノートを共有するツールを使うことが多い。 エクセルは設計書に使わない。

フロント+Netlify Functionのような構成をAWSでやる場合にLambdaを管理するには何がオススメですか?(CDK、Amplify、ServerlessFrameworkなど)

Amplify

同時実行数とバースト制限(Cold Start時)のほかに、スロットリングしてしまうLambdaの仕様はありますか。

無いと思う。

LambdaLayerを単独スタックにした場合、他のスタックから参照されているとLayerを更新できないと思いますがLayerを別スタックにするのはよくないですか?

今すぐの回答は無いので、考えたい。

AWSで働いていて、一番やりがいを感じる時はどんな時ですか?

色々あるので飲み会ででも。

SAとして働いていて、自分でプロダクトを作り切りたいという欲求に駆られることはありますか?

今はもうなくて、広い範囲でいろいろなことをしたい思いが強い。

s3からlambdaへputトリガーでinvokeする場合に、稀に非同期のためinvokeされないケースがあると思いますが、どのように救うのが良いでしょうか?

SQS 使ったり、処理したらバケットを移動させるなど、担当の SA に相談ください。

所感

お便りコーナー全部答えるのがすごい...
今回も話せる範囲で色々仕組みを聞けたので勉強になりました。

Developers.IO CONNECT 2020 DAY7 これで最後 #devio2020

DAY6 の続き。

カルチャーを聞けるセッションって珍しいですよね。

就職せずに自己資本でクラスメソッドを起業して16年掛けて年商200億円になった話

www.youtube.com

再生回数がイベント登録者を上回ってます。
しくじりを赤裸々に語ってます。

2008年新規事業の副産物で EC2 と出会うとい部分がキターという感じで盛り上がっていいです。
クラメソが AWS 本格的にやり始めるより先に、自プロダクトでの利用の方が早かったというのが驚き。
やり始めた 2012年頃から JAWS に参加してれば違う未来が待ってたんだろうなと...

チーム運営でも真似したいメモ。

  • 企業理念とカルチャーの明文化
  • 現場より責任者やマネージャーを優先採用
  • 担当者を信じる
  • 潰れても戦える社員
  • 情報発信に勝るマーケはない
  • 事業規模はマーケサイズに依存

とりあえず技術ブログ

  • 特定の技術について毎日書く
  • ネットでの反応ヨシ
  • 勉強会やってみよう
  • ユーザーグループの誕生

発信すればするほど反応がある

新規事業のチャレンジでやってよかったこと

  • 低コストでスタートして繰り返しピボット
  • 情熱を持てる当事者を中心にメンバー集め
  • 透明性のある情報共有
  • マーケットの将来性
  • 販路
  • 継続的な改善
  • キャッシュアウトを支える基盤事業

クラスメソッドとNTT東日本で作った新会社 ネクストモードの紹介 #devio2020

www.youtube.com

クラウドであたらしいはたらき方を」をミッションに。
スピードや柔軟性を求めるモード2へ。大企業だと全社でモードは統一されず、部署ごとにモードが違ったりする。 こだわることと、こだわらないことを宣言してすすめる。

こだわらないことのほうが大事なことを書いていると感じました。

  • 完全性
  • 普遍性
  • 年単位の改善
  • 使う前の修正
  • 規模
  • 内製

企業には、既存のオンプレミスのシステムがあって、クラウドの導入に反対する人がいる。

社員のモチベーションをあげると全体の生産性があがる。 登記簿や労基署への提出は、印鑑や FAX 、郵送が必須で、役所の取引は変えれない。 民間の取引は変えていくことができる。 freee を利用し、すべてクレジットカードで決済をして現金を扱わない。 代表電話が無い。Amazon Connect で電話を受けて、Slack へ番号を通知して、折り返す。 クラウドの導入に反対の人に対しては、触ってもらいファンになってもらう。

NTT の電話の強みと、ClassMethod のクラウドの強さを融合させ、現場に降りてきて自ら実践を行い、それを商材として扱っている感じでした。

より良い登壇を目指して今すぐできること re:Master #devio2020

www.youtube.com

「登壇ほぼしたことない人が喋ってみるのも面白いかも」が動機。
自分の言葉で話す、スライド読み上げマシーンにならない。 など、登壇する際に気をつける点を解説してました。
登壇あまりしたことないとは思えないプレゼンでした。

ユーザー体験向上するためにAWSサポートチームでやってる10のこと #devio2020

www.youtube.com

毎年 1.7 倍のサポート量が増えている。
必ず数字で語る DIKW モデル

エスカレーションしやすさの仕組み、してもいいという雰囲気
Zendesk から Slack へ連携

圧倒的な自動化
ITIL 上での自動化
人しかできない仕事に集中する

root 使わない運動
root キー漏洩マニュアルも作ってる

感謝を忘れない!

今日からはじめるAWS #devio2020

www.youtube.com

独学で AWS の勉強を始めた。良かった方法を共有したい。
プログラムだけだと不安があったのでインフラも知りたかったから勉強をした。

Umedy 優秀、アソシエイト本で勉強で資格取得。
公式ハンズオン、BlackBelt、公式チュートリアル、トレーニングを活用。
AWS 知識を得たら、インフラ知識の底上げすることで、AWS サービスの理解が深まる。
アウトプット、人に見られることを意識するのであやふやに気づける。繋がり増える。

おすすめ書籍

  • インフラエンジニアの教科書
  • インフラエンジニアの教科書2
  • マスタリング TCP/IP
  • ネットワークはなぜつながるのか
  • 絵で見てわかる IT インフラの仕組み

モチベーション高い人とつながってるのがモチベーションのもと!

所感

カルチャーの明文化は難しいですが見習いたいところ。
モチベーション高い人が高い人を呼んで、相乗効果でさらによくなるスパイラルになってて羨ましい限りです。

DAY7 もあったおかげでかなりのボリューム感と満足度でした。
ありがとうございました。

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

#1 に引き続き #2 の受講メモ。

serverless.connpass.com

ハッシュタグ#serverlessjp

アーカイブ

Access to multiple microservices on AWS

speakerdeck.com

GraphQL

  • エンドポイントは1つだけ
  • Query, Mutation, Subscription の3つのオペレーションが行える
  • 1回のクエリに複数のリクエス
  • レスポンスに必要な要素をクライアントが指定
  • フィールドごとにクエリを入れ子にできる

GraphQL は POST の Payload で query getXXX とかする感じかな。
POST だけど Get すると...REST思想だと気持ち悪い気もする。

AWS AppSync

マネージドな GraphQL サービス、以下のデータソースで利用可能

  • Lambda
  • DynamoDB
  • Elasticsarch
  • Aurora Serverless
  • HTTP Endpoint

まとめ

  • AppSync はフロントエンドの処理をシンプルにしやすい
  • 各マイクロサービス API の手前に AppSync を置くとマイクロサービスの課題を解消しやすい
  • Cognito と組み合わせで細かな認証や APIG の認証にも使える
  • CloudWatch Logs Insights や X-Ray などのサービスも使うと捗る

Azure Static Web Apps で実現する Serverless CMS

speakerdeck.com

SSG - Static Site Generator (Hugo とか)なお話。
Hugo 便利ですよね、GitHub -> CodeBuild -> S3 -> CloudFront だけで簡単にサイトができてしまう。
Azure 使ってないので、ほほーという感じでした。

RDS Proxyの話

GA されて話題沸騰 RDS Proxy のお話。
内容は別記事でメモってる内容と被るので省略。
Lambda + Aurora を利用しているケースはあるけど、負荷が少ない部分のみで利用しているので、ここにコストをかけて組み込むのはなかなか難しい。
西谷さんも「騒がれてても実際に使われるのはまだまだ」とのとこ。
まずは試すところから始めないと始まらないが必要に迫られてからでもいいか。
ECS + Aurora でもメリットがでそうならやりたい。

所感

FONTPLUS DAY から引き続き見てました。
遅い時間に開催してくれるのは見やすくて助かります。

Serverless の話は面白いなー。
GraphQL いい話ばっかり聞くんだけど、学習コストも含めて使うのに辛い面は多くないんだろうか?
React と同じく Facebook 制はハードル高いけど覚えれば効果は高そうです。

Developers.IO CONNECT 2020 DAY6 MAD #devio2020

DAY5 + DAY6 の続き。

MAD 編は興味があるのでとてもおもしろい。

マイクロサービスのその先へ ~AWS App Mesh Service と AWS Cloud Map~ #devio2020

www.youtube.com

モノリシックは悪いわけではない。 スケールさせる時に問題が出る。

Amazon も問題が出てからマイクロサービスへ変更。 組織とセットで変革させる。 コンウェイの法則。

アジャイルだからドキュメントは後回しは勘違い。 API のアップデートの通知には必要。

アジャイルの考え方は、クラウドの考え方とかなり親しい。 しかし大型のリリースは、ウォーターフォールに親しい。

各サービスの責任者がそれぞれ独自に判断してリリースを行う。

オンプレミスはインフラに流動性がないので、メリットが少なくなる。

AWS App Mesh アプリケーション間の通信を管理 Envoy proxy (OSS) を利用している。

基礎から応用までじっくり学ぶECS Fargateを利用したコンテナ環境構築 #devio2020

www.youtube.com

ECR : イメージ脆弱性スキャンもしてくれる

クラスタ > サービス > タスク <-- タスク定義 <-- コンテナ定義 <-- ECR

DB 接続情報は環境変数、SSM や Secret Manager 利用する。

定期実行でのバッチ処理

  • 起動だけなら Fargate のタスクスケジューラ
  • 並列ジョブや配列ジョブを利用するなら AWS Batch
  • SQS + Lambda or Step Function も検討したほうがいい

ログ

ドライバを設定して出力する。

  • awslogs ドライバ
  • Splunk ドライバ
  • Fluentd ドライバ

CloudWatch Container Insights でタスクやコンテナ単位のメトリクスを取得

X-Ray

Docker コンテナに X-Ray SDK を追加する。
X-Ray サイドカーコンテナで出力。

サンプリングでとるので、完全制(すべてのログを取るわけでは無い)は無いので注意。
ボトルネック調査用。

サーバーレスシステムのチーム開発 #devio2020

www.youtube.com

  • AsciiDoc と PlantUML でシーケンス図作成
  • Swagger UI で API 設定を定義
  • Draw.io で AWS リソース構成を設計

AsciiDoc だけは使わず Markdown でやってます。
それ以外は使うようにしていて、それぞれ便利ですね。
テキストで管理できるので、リポジトリに放り込んでバージョン管理できるのが便利。

AWS CDK + Step Functions 入門 #devio2020

www.youtube.com

AWS StepFunctions

  • ワークフロー作成
  • ステートマシン
    • ワークフロー処理全体のこと
    • ステートマシン一つ一つの処理単位のことを State と呼ぶ

StepFunctions 便利らしいけど使ったことがない...

所感

DAY6 の Modern Application Development は、興味があることが多くて楽しかった。
手を動かしたこと無い項目も多くあるので X-RayStepFunctions はやりたい。

「今からでも遅くない。ECSで始めるコンテナ運用 #devio2020 」と共に AWS Copilot を試してみる

ECS をちゃんと触ったことがないので、マネジメントコンソールと噂の AWS Copilot 試してみます。
Copilot を検索すると、副操縦士とでてきますね。 この意味からとったのかな。

今からでも遅くない。ECSで始めるコンテナ運用 #devio2020

www.youtube.com

コンテナの基本の説明から。
タスク定義、タスク、サービスが図示されて概念がわかりやすい。

動画の説明通り、マネジメントコンソールでポチポチするだけで、ECS Fargate を起動することができました。
ECS って、ALB の準備が前提と思ってましたが、Fargate だと ALB を経由しなくてもアクセスできるんですね。
EC2 タイプだけが ALB 必須なんだろうか...それとももともと勘違いしてて不要だったのか?

AWS Copilot

本日発表されて話題沸騰の AWS Copilot

トリさん翻訳の公式とハマコーさんのブログをそのまま試してみました。

aws.amazon.com

dev.classmethod.jp

初回デプロイに 10 分ぐらいかかるけど、 VPC + ALB + ECS Fargate を用いた環境が簡単に作成されました。
デプロイに時間がかかっているのは、CloudFormation のログを見る限り、作成するリソースが多いうえに ALB の作成がそもそも重いのが原因でしょうか。

Serverless FrameworkAWS SAM を使って、簡単に API を作れたのと同じ感覚でインフラをあまり意識せずに作成できてしまいました。
API Gateway + Lambda をよくわからずに作って苦しんでいた時に sls コマンドでサクッとできてしまったのと同じ感動です。

Copilot には、サービスタイプが2種類準備されてます。

次にサービスのタイプを聞かれます。2つ選択肢がありますが、大きくは以下の違いです。

  • Load Balanced Web Service:インターネットフェーシングなパブリックサービス
  • Backend Service:プライベートなバックエンドサービス

ハマコーさんブログより引用)

ハマコーさんブログ手順で Load Balanced Web Service を試したので、 copilot app delete で一旦作成した環境を消してから Backend Service も試してみます。
コンソールログでの違いは、最後のデプロイ部分。

$ ✔ Deployed copilot-backend-svc, its service discovery endpoint is copilot-backend-svc.exsample-copilot-app.local:80.

ローカルに作成されたログがでました。
ここにアクセスするには、VPC 内に EC2 とか立てないと試すこともできないですね...

copilot 利用時に、EC2 タイプを利用した ECS の作成は見当たらなかったのですが、できるんだろうか?

追記

やっぱり、Fargate のみですね!
トリさんありがとうございました。

所感

ECR 使わないケースで、公開されたコンテナを利用するのであれば、マネジメントコンソールで Fargate を利用することにより、比較的簡単に作成できます。
一方、自作の Dockerfile を利用したい場合は、 ECR にあげる手間暇が通常はかかりますが、 copilot を利用することによりその辺りも含めてとても簡単にデプロイができます。
手元の Docker を AWS でも手軽に利用したいときには、とても役に立ちそうです!

「JAWS-UG CLI専門支部 #163R CloudWatch Logs入門」受講 #jawsug_cli

jawsug-cli.connpass.com

運用はもちろんのこと、Lambda デバッグでもお世話になる CloudWatch Logs です。

基礎知識

CloudWatch は全体像の把握が難しいぐらい増えている。

CloudWatch の全体像

API 対応するサービス名
cloudwatch CloudWatch メトリックス
CloudWatch アラーム
CloudWatch ダッシュボード
CloudWatch Contributor Insights
application-insights CloudWatch Application Insight
logs CloudWatch Logs
synthetics CloudWatch Synthetics
events 旧 CloudWatch Events

CloudWatch Logs の概要

イベントログの記録、保存、取得。
料金もこの3箇所で綺麗に別れている。

統合CloudWatchエージェント を利用すればEC2だけじゃなくてオンプレでも Logs に保存できる。

CloudWatch Logs の要素概要

イベントログ保存の3要素が親子関係になっている。

  • ロググループ
    • ログストリーム
      • ログイベント

これらを メトリックフィルター で抽象化して CloudWatch に飛ばせる。
サブスクリプションフィルター 利用で生ログを Kinesis に飛ばせるけど、お金かかるので注意。

記録は細かく、ログストリームで。
取得はざっくり、ロググループで。

公式ドキュメント

160 ページで少ないほう。 全部ちゃんと読むと丸一日ぐらいのボリューム。 AWS はドキュメントに答えがあるのでコツがいるけど必要に応じて読むほうがいい。

ログの保持期間

保持期間はデフォルト無制限で、ほっとくとお金がかかるので気をつける。
法律的なものは7年間がおすすめ。
13ヶ月、33日とか切りが良いものより、ちょっと伸ばすのがコツ。
中途半端な期間は、マネジメントコンソールからできないので、CLI で対応する。

CludFormation についての余談

  • 2階建ての知識なので(初心者には?)おすすめしない
  • 引き継ぎが辛い
  • 30回使うならいいけど、作るのが目的になりがち

(;^ω^)

ハンズオン

資料は connpass からリンクされている こちら
いつもどおりポチポチコピペで進むので、マネジメントコンソールで確認しながら行うとわかりやすい。
CloudWatch もリージョンサービスなので、東京リージョンに切り替えて確認する。
2件目以降に aws logs put-log-events する場合は、結果整合性など優先順位も大事だから --sequence-token が必須になると思われるとのこと。

所感

CloudWatch と CloudWatch Logs は別物だけど自分の中では一緒くたになりがちでした。
AWS について会話してても、意識的に使い分けができず、どちらも CloudWatch と呼んでました。
CloudWatch Logs についての基礎知識の話を聞いて、今更ながらちゃんと理解できた気がしました。

概念としては理解できたものの、AWS リソース構築する時にデフォルトで出力される CloudWatch Logs しか使ってない気がします。
この辺りちゃんと考えるようにしないと...あと無制限保存は見直し必須!