amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

ダム際でコーヒーを

目次

初めに

この記事は、Coffee Advent Carendar 2022 第1日目の記事です。

adventar.org

毎年恒例のCoffee Advent Carendarがはじまりました。 初日は私amarelo(アマレロ)が書きます。

「1人でどこか気の向くままに出かけてのんびりしたい。」

ある日の仕事中、ストレスが溜まっていたのか、急にそんな思いが湧いてきました。

たまには自分だけのために休暇を取って気晴らしした方が良いと思い、以前からやってみたかったダム巡りに行こうと思いました。

そこでコーヒー淹れて飲んだらのんびりできて気持ちいいだろうなぁと思い、9月と10月にダム際コーヒーをやってきました。

2022/9/9 群馬県みなかみ町 藤原ダム

藤原ダムについて。 www.ktr.mlit.go.jp

9月前半の日中帯はまだ暑いと思い、自宅でアイスコーヒーを淹れて持っていきました。 ダム湖を眺めながらアイスコーヒー、はじめてのダム際コーヒー。広大なダム湖と自然を眺めて癒されました♪

ダムからの帰りに立ち寄った川のほとりでもう一杯。

ダム際ではないですが、水上駅から上越線土合駅に行き、駅舎内にある駅茶モグラにてもう一杯アイスコーヒーをいただきました。 土合駅は別名モグラ駅ともいわれており、地下ホームから地上までの階段は486段強! 疲れましたが、その疲れた体に染み渡るアイスコーヒーでした。アンバタートーストも美味しかった♪

2022/10/14 埼玉県秩父市 浦山ダム

浦山ダムについて

ja.wikipedia.org

情報処理技術者試験が終わって間もないころだったので、気分転換しようと思い行ってきました。 この日は朝からあいにくの雨。浦山ダム到着時も雨で霧がかかっていましたが、幻想的な風景に見えて心躍りました♪

先に昼食を済ませて雨脚が弱まってきたところを見計らって、ダム際でコーヒーを飲みました。 雨の予報だったので、この日はホットコーヒーを自宅で淹れてきました。 山に軽く霧がかかった景色を見ながら飲むコーヒー。なかなかできない景色と経験でした。

午後に差し掛かって雨は完全に止んだので、天端のベンチで読書をしてから帰りました。 浦山ダムは天端が広く、のんびりコーヒー飲んだり読書するにはうってつけの場所だと思いました。 2週間くらい前に行っていたら、紅葉がキレイだっただろうなぁと思います。行けばよかったなぁ。。。

最後に

自然の中でのんびりとコーヒーを飲みながら読書をし、ダムのある町を観光して過ごす休日。

家にばかり居続けるのにも疲れが出てきたので、景色を変えることで良い気分転換になり気持ちよく過ごすことができました。 また、今回のようにコーヒーの楽しみ方を実践と追及して発信していくのは、コーヒーを広めるための活動の一つだなと思いました。 車は使えなかったので公共交通機関を使っていきましたが、小旅行のような感覚も味わえたのも良かったです。 スケジュールを調整して定期的にダム巡りとダム際コーヒーをやり続けたいと思います!

短いですが、今日はここまでにします。最後まで読んでいただきありがとうございました!!

JAWS-UG朝会 #39 参加レポート

3か月ぶりの更新になってしまいました。ブログ書けなくなっていましたが、少しずつ書いていこうと思います。

本題です。11/9、自分の中では毎月恒例になったJAWS-UG朝会 に参加しました。

先月先々月は参加してたものの書けませんでしたが、今月はようやく書けました。

目次

イベントページ

jawsug-asa.connpass.com

セッション内容

(今更ながら)AWSのコンテナサービスについてざっくりまとめてみる クラスメソッド株式会社 つくぼしさん

コンテナとは?

  • アプリケーションのコード、構成、依存関係を単一のオブジェクトにパッケージ化する(AWS公式より)
  • chrootがコンテナの元祖と思われる。
  • 仮想ファイルシステムの分離をできるpivot_rootが登場し、その後Dockerが登場。
  • つまりコンテナとは、高機能な仮想ファイルシステム
  • コンテナレジストリ
  • コンテナオーケストレーション
    • 複数のサーバを麻袋でコンテナを管理する機能
    • 一部のサーバが停止した際にコンテナを別サーバで再起動する。

AWSのコンテナ主要サービス

  • Amazon ECR
    • AWSが提供するマネージドプライベートコンテナレジストリサービス
    • アクセスにはAWSの認証情報が必要
    • ECSやIAM等の連携が容易
    • 自前でプライベートコンテナレジストリを運用する必要がない。
  • Amazon ECR Public
    • マネージドパブリックコンテナレジストリサービス
    • AWS認証情報なしでアクセス可能。
    • イメージPull回数制限がない。
    • Docker Hubの代替手段として利用できる。
  • Amazon ECS
  • Amazon EKS
  • AWS Fargate
    • コンテナ用のサーバ管理が不要な起動タイプ
    • クラスタ基盤であるEC2を運用する必要がない。
    • 一部機能制限がある。

AWSのコンテナ関連サービス

  • AWS App Runner
    • マネージドコンテナデプロイサービス
    • コンテナイメージURI、サービス名、CPUメモリ、ポート番号を指定するだけでデプロイ可能。
  • AWS Proton
    • デプロイワークフローツール
    • インフラ基盤担当とアプリ担当に分かれて、コンテナ基盤を柔軟に運用できる。
  • AWS Copilot
    • ECSを構築するための専用CLIツール
  • AWS Cloud Map
    • マネージドサービスディス賀張サービス
  • AWS App Mesh
    • マネージドサービスメッシュサービス

資料

speakerdeck.com

セッション② 企業のシステム棚卸業務にSSM Inventoryで挑む カスタムインベントリの全て 株式会社ビックツリーテクノロジーコンサルティング 熊谷 有輝子さん

構成管理とは

  • システムを提供運用するために必要な物理資産の状態や文書を人が確認できるように管理すること。

SSM Inventoryとは

  • OS上のアプリ一覧など構成情報を記録
  • 可視化のための簡易的なダッシュボード機能を提供
  • 標準インベントリでアプリケーション、AWSコンポーネント、ファイルなどの情報を取得
  • マルチアカウント構成下でのインベントリ情報も収集可能

カスタムインベントリ

  • 取得できる情報
    • オンプレミスのサーバラック位置に関する情報
    • オープンソースAPI利用有無
    • 所定のファイルパスは以下にカスタムインベントリとして収集したい情報をJSONに記載したものを置く。
  • JSONファイルの情報は定期的に更新しなければならない。

SSM State Managerを用いた構成管理

  • 定義された状態にサーバを保つプロセスを自動化する。
  • サーバの状態を確認、是正するための定期的な処理に向く。
  • 定義したスクリプトを所定の時間に実行
  • スクリプトをSSM Documentとして管理できる。
    • SSM Custom Documentの作成
    • スクリプトの作成
      • カスタムインベントとして収集したい情報を作成する。
    • Associationの作成

カスタムインベントリ機能の制約

  • マルチアカウントの横断分析はSystems Managerではなく、Athena,QuickSightで確認する必要がある。

資料

speakerdeck.com

LT① 定期バージョンアップ、私の苦手な言葉です。(EKS/Aurora編) KDDI 御田 稔さん

  • Amazon EKS

    • EKSのアップデートサイクルが12か月間サポートに変更。
    • 半年に1回くらいはバージョンアップしたいところ。
    • 機能増減や仕様変更も激しい。
    • リリースは、ブルーグリーンデプロイで新規クラスタに移行。
      • DNS切り替えだけでなく、ELBのターゲットグループの付け替えで切り替えするシステムもある。
  • Amazon Aurora

    • メジャーバージョンは3年ごと。マイナーバージョンアップは1年ごとを目安に更新したいところ。
    • 普段やってる開発タイミングを見計らって検証してもらえるよう、アップデート計画を立てている。
    • 事前にスナップショットを取ってバックアップしておき、インプレースで更新する。
    • マイナーパッチングでブルーグリーンデプロイしている人がいるか気になるので、他の人の事例も知りたい。

資料

speakerdeck.com

LT② JAWS DAYS 2022にボランティアスタッフとして初参戦してみました クラスメソッド株式会社 あしさん

  • 会社のSlackチャンネルの投稿を見て、何も分からないけど応募した。
  • 動画配信のオペレーションを担当した。
    • 配信画面の切り替え、幕間動画の切り替えなど
  • オフラインで参加して良かったこと
    • イベントの熱気を身をもって体感できた
    • 登壇者の話を至近距離で聞くことができる。
    • イベントの一部になれた。
    • オフラインならではの出会いがあった
      • 双方向かつ偶然のコミュニケーション
      • 配信担当、打ち上げで一緒になった人と仲良くなれる。
    • お世話になったJAWS-UGに貢献できた。
  • 学びの方程式
    • 興味、義務、情熱、これらを掛け合わせたものがっけか
    • コミュニティ登壇や運営はこれに当てはまるのでは?

資料

公開されたことを確認出来たら追記します。

LT③ Lambda拡張機能を使ってLambdaパフォーマンスを上げよう BeeX 那須 隆さん

  • Systems Manager Parameter Storeからのパラメータや、Secrets Managerのシークレットを取得するレイテンシとコストを削減でき、アプリケーションのパフォーマンスを向上できるようになった。
  • 計測してみた。
    • SDKで取得と比較すると、半分以下の時間で済んだ。
  • APIリクエスト回数の上限がある。
    • Parameter Store:40TPS(スループット制限の上限緩和可能)
    • Secrets Manager:5000TPS(上限緩和不可能)

資料

speakerdeck.com

最後に

コンテナ何もわからなかったので、コンテナのお話は凄くしっくりきました。分かりやすかったです。SSMについても資格試験勉強している者としては、とても参考になるお話でした。

ボランティアスタッフ参加のお話では、またオフラインイベント参加したい気持ちにさせられました。オフラインイベントのボランティアスタッフや運営は、人見知りコミュ障の自分はどうしても二の足踏んでしまいますが、機会を作って挑戦してみたいと思いました。

今回は以上になります。ありがとうございました!

JAWS-UG朝会 #36 参加レポート

久々のブログになってしまいました。 8/4 JAWS-UG朝会 #36 に参加しましたのでレポートを書きます。

目次

イベントページ

https://jawsug-asa.connpass.com/event/245634/

セッション内容

セッション① AWSのコンテナイメージスキャン手法をまとめてみた クラスメソッド株式会社 たかくにさん

コンテナセキュリティ

  • ECRイメージスキャン(ベーシックスキャン)
    • 手動スキャン(24時間に1回)と自動スキャン
    • Clair プロジェクトのデータベースを使ってスキャン
    • 無料
    • 導入しやすい
  • ECRイメージスキャン(拡張スキャン)
    • Inspectorがサービスロールを使ってスキャン
    • 複数のデータベース(Snykなど)を使用
      • Snykのデータベースの一部を使っている
      • 有料
    • OSに加えてプログラミング言語パッケージもスキャン対象
    • Security Hub、Organizationsとの統合
  • docker scan
    • docker-scan-pluginを使ってローカルのDockerイメージに対して行うスキャン
    • Snykを使用
      • Snykとは
        • 開発者が利用するために作られたセキュリティプラットフォーム
    • 無料
  • Docker Hub上で脆弱性スキャン
    • 有料
  • Snyk Container
    • Snykデータベースを使用
    • OSに加えてプログラミング言語パッケージもスキャン対象
    • 日次や週次の定期スキャン
    • 新しいCVEが公開されたら自動でスキャン
    • 無料プラン(100回/月)と有料プランがある

資料

speakerdeck.com

セッション② インフラのテストにVPC Reachability Analyzer は外せないという話 株式会社ヌーラボ 中野雅之さん

ネットワーク疎通テスト

  • 手動でやるとサーバ増えた時に無理
  • ツールに頼る必要がある

Serverspecとawspec

  • Serverspecとは?
    • Ruby製のOSS
    • サーバのプロビジョニング状態やネットワークレベルの疎通確認ができる。
  • awspecとは?
    • AWSリソースに対する設定のテストができる
  • 気になる点
    • コンテナやALBを起点とした場合の確認は?
    • VPC Reachabbility Analyzerの使用

VPC Reachabbility Analyzer

  • AWSリソースに対するネットワークレベルの疎通テストを行うことができる
  • ただ、一度作成したパスは編集ができないので再作成する必要がある
  • ECS FargateのようなENIがコロコロ変わるリソースとは相性が悪い
    • ENIのタグ名がコンソール上では表示されないのでわかりづらい
    • AWS CLIを使う
  • Serverspecやawspecを併用して手厚いテストを実施可能

資料

speakerdeck.com

LT① シェルスクリプトAWSをいい感じに使いたい shimoさん

  • シェルスクリプトを使ってAWS操作を自動化
    • 覚えることが減る
    • 時短できる
    • オレオレ魔改造になりがちになる
  • EC2インスタンスSSH接続
    • VPC接続を確認
    • 複数EC2から選択
    • EC2を起動してIPを受け取る
      • start-instancesで起動
      • 出力は 2 > $1 > /dev/null で捨てる
    • SSHログインする
  • これらを順番に.shファイルに書いていけば出来上がり

資料

docs.google.com

LT② サーバレス開発が地味にキツイ、特にDynamoDB NTT東日本 長久保聡さん

  • 仕様変更や機能追加の時にきつくなる
  • GSIを安易に付与するとテーブル設計が崩壊する。引継ぎが辛くなる。
    • RDBみたいな構造になっていく
  • scanはscan全体で課金される。
  • マイクロサービスが上手く構築されていないのが原因

資料

※公開され次第追記

LT③ 年700万円損するサーバレスの認可システムをご紹介します!! 生活協同組合コープさっぽろ 樋口修也さん

  • 認証認可とは?
    • 認証:端末の使用者が誰かを明確にする
    • 認可:誰に何をして良いかを確認する
  • 複数APIあるとレガシーidの管理が大変
  • 認可用のAPIを作るとアクセスが集中してコストと保守工数が発生してしまう
  • Auth0上のmetadataにレガシーidを持たせる
    • 複数APIもOK
    • id変更も一括で可能
  • トークンの認可を各APIで処理するとお得になる

資料

speakerdeck.com

最後に

DynamoDBのscanはDB全体へのスキャンにお金がかかること、初めて知りました。 自分が作ったTwitter BotでDynamoDB Scan使っているので、レコード増やし過ぎないように気をつけなければと思いました。 AWS CLIシェルスクリプトの活用、まだまだやれていないことあるので、今日シェルスクリプトの話を聞けて刺激になりました。

最近ブログ更新出来ていませんでした。勉強会には色々参加しているんですが、サボり癖がついて良くないですね。。。アウトプット大事! 朝会の登壇も希望者が増えてきて内容が濃くなったので、自分が登壇する時ももっと内容と精度を高められるようにしなければ。。。

JAWS-UG朝会 #34 参加レポート

6/7 JAWS-UG朝会#34 に参加しましたので、レポートを書きます。

目次

イベントページ

jawsug-asa.connpass.com

セッション・LT

セッション① AWSを活用して社内ISUCONを開催したはなし 野村総合研究所 山口渡さん

ISUCONとは

  • 8時間の間にWebサービスを限界まで高速化するチーム対抗の性能改善テスト。
  • 今年は7月に予選、8月に本選を開催される。
  • 運営が準備したベンチマークを使って各チームのWebアプリケーションのスコアを算出する。
  • 参加者は、計測→改善→ベンチマーク のサイクルを回す。

高速なアプリケーションとは

  • 多くの人が快適に利用できるアプリケーション
  • 拘束はWebアプリケーションの必須要件。
  • Webアプリケーションを高速化するには、ボトルネックを特定・計測して改善する。
    • フロントエンド、バックエンド、両方の改善(チューニング、最適化)が必要であり、幅広い領域の知識が必要。

社内ISUCONを企画

  • 人材育成、人材発掘、社員同士の交流の場の提供を目的に。
  • インフラ系だけでなくアプリやセキュリティ系など、幅広い職種の人に参加いただけた。
  • 普段の本業で関わらない領域にチャレンジできる。

競技者用インスタンスの概要

  • OSレイヤー以上の改善のため、EC2を利用。
  • チームごとに踏み台サーバのEC2インスタンスを4台 × 28チーム = 112台構成
  • TeraformとAnsibleで構成管理

ポータルサイトの概要

  • 運営から競技者に、競技中に必要な情報をや機能を提供
  • SPA+サーバレス構成
    • フロントエンド:React + CloudFront + S3
    • バックエンド:APIGateway + Lambda + DynamoDB

ベンチマーカー

  • Webアプリケーションの性能を評価しスコアを算出する
  • Golangで実装・コンテナ化
  • AWS Batch for AWS Fargateで構築
    • ポータルサイトからのベンチマーク実行をトリガに、LambdaでBatchジョブを作成。
    • ジョブを作成してから30秒程度で開始。
    • ジョブごとにCloudWatchで確認可能。

当日の運営

  • ベンチマークの不具合事象が発生。
  • ファイルディスクリプタの上限を上げようとしたが、Fargateでは設定を変えられないことが判明。
    • 一部の異常系でHTTPコネクションの解放処理に不具合
      • ベンチマーカーのテストをローカルのDocker環境で実施していた。
      • ローカルのDocker環境のファイルディスクリプタは異なり、枯渇することはなかったため。

資料

speakerdeck.com

セッション② スタートアップでどのようにControl Towerを導入したか WHITE CROSS株式会社 Kazuki Oguraさん

以前のAWSアカウント運用の問題点

  • 単一のVPC内で複数のプロダクト・環境が稼働していた
    • 管理の煩わしさ
    • セキュリティ面んお不安
  • IAMユーザ、ロールの管理が統制されていなかった
    • 危険な操作が行われる
  • AWS Control Towerの導入をAWS SAから提案された

Control Towerとは

  • AWSマルチアカウント環境をセットアップ及び管理するための簡単な方法を提供する
  • landing zoneを1時間未満で構築できる(Organizations,Service Catalogなどを使用)
  • Organizationsを使用してマルチアカウント環境を作成
  • AWS SSOのデフォルトのディレクトリを使用してID管理を提供
  • ガードレール
    • AWSのベストプラクティス及びガバナンス向けの一般的なカスタマーポリシーに基づく厳選されたガードレールのセットを提供
    • ルールは企業全体または特定のアカウントのグループに提供可能
    • ガードレールには必須、強く推奨、選択的の3種類が存在する
    • 新しいガードレールがリリースされうr
  • 必須ガードレールの例
    • Control TowerやCloudFormationで設定されたIAMロールを変更不許可にする
    • ログアーカイブの公開読み取りアクセス設定の検出
  • 強く推奨
    • EC2インスタンスにアタッチされたEBSボリュームの暗号化が有効になっているか検出
    • RDSデータベースインスタンスへのパブリックアクセスが有効になっているか検出
    • SSHを介した無制限のインターネット接続が許可されているか
    • ルートユーザのアクセスキーの作成を許可しない
    • S3バケットへのパブリック読み取りアクセスが許可されているかを検出
  • 選択的ガードレール
    • VPCインスタンスのインターネットアクセスを禁止
    • EBSスナップショットがすべてのAWSアカウントで復元可能かどうか
    • リクエストされたAWSリージョンに基づいてAWSへのアクセスを拒否する
    • S3バケットバケットポリシの変更を許可しない

Control Tower導入までに行ったこと

  • OUの設計
    • OUは多層にすることはできない(Organizationsはできたはず)
  • 権限設定
    • アカウントの所属グループと権限
    • グループに所属させるユーザ等
  • ルートアカウントの管理方法検討
    • ユビキーによるMFAを採用
      • 専用スマホを準備するのに費用がかかる
      • 個人スマホに紐づけると紛失したり、退職時に上手く引き継げない恐れがある

Control Towerを導入した感想

  • 抱えていた仮題を解決できた
  • OrganizationsとSSOを用いたマルチアカウント運用がとても簡単に導入できた
  • CloudTrailやConfigなどのセキュリティサービスの導入も簡単に出来た。

Control Towerを導入すべきか

  • 既にマルチアカウント運用がうまくできている組織
    • 導入コストに比べてメリットを享受しづらい
    • ガードレールが使える
    • 正確なLanding zoneを使うことができる
  • まだマルチアカウント運用ができてきない組織
    • ぜひControl Towerを導入するべき!!

LT① Lambdaで最近やらかした話 もつさん

  • Kinesisから送られてくるデータを抽出して、別のSaaSへのAPI連携をさせるために、Lambdaで実行させようとしていた。
    • Lambdaでは対象のレコードを取得して、Kinesisから必要な情報を抽出し、SaaSの対象レコードにPOSTしようとしていた。
  • テストを繰り返していたところ、CloudWatchでは秒単位でエラーログが出続けていた。
    • Kinesisのデータ連携をすぐに止めた。
    • Lambdaの再試行パラメータ数値を低くした。
      • kinesisのデータ保持期間は24時間のため、もっと早めに中断させるため。
  • 原因
    • kinesisとの連携ではイベントソースマッピングを使用しているため、失敗するとKinesisのデータ有効期限が切れるまでひたすら繰り返す。
    • Lambdaの処理の中に無限ループから抜けられないものがあった。
  • 反省
    • 想定しない件数が出た時のためにCloudWatchアラートを入れておくべきだった。
      • もう少し早めに気づけた可能性があった。
    • 複数処理の分散のためにStep Functionsを使うことも考慮しておけばよかった。

資料

speakerdeck.com

LT②うわっ…AWSのセキュリティ系サービス、多すぎ…?オンプレエンジニアにも分かりやすく整理してみた KDDI 御田 稔さん

  • セキュリティ事故が起こると大問題になるが滅多にないため、正常性バイアスになりがち。
  • 何かあった時に一番困るのは責任者で、組織が大きいほど各担当の自分事意識が薄れがち。

AWSとオンプレの違い

  • 簡単に全世界から攻撃される。
    • セキュリティ知識なしに使うとすぐ事故につながる。
  • マネージドサービスの場合は、利用者が気にしなくていい部分が増える。

ネットワークセキュリティはオンプレと似ている

  • ファイアウォール
  • OSソフトウェアの脆弱性
    • Systems Manager
      • インベントリでソフトウェアバージョン一覧を抽出
      • パッチマネージャーでパッチの自動適用
    • Inspector
    • アナライザー
      • IAM Access Analyzer
        • ポリシ設定状況を可視化
      • VPC Reachability Analyzer
        • リソース間接続の正常性確認
      • Macie

有効化するだけのサービス

  • Config
    • リソースの変更記録
  • Security Hub
    • 自アカウントの危険性を把握
    • セキュリティ系サービスの出力結果を統合
  • GuardDuty
  • Security HubとGuard Dutyは30日無料お試し可能。トライアル中に推定コストを出してくれる。
    • とりあえず30日使ってみよう。

万が一インシデントが発生した場合

  • Amazon Detective
    • 被疑リソース周辺の怪しいログを可視化

資料

speakerdeck.com

LT③ アプリ側のコードを書いていた人がLambdaに触れて気づいたこと さき(H.Saki)さん

  • main関数とハンドラ関数が別に用意されている。
  • 2つのLambdaのスタート方式
    • コールドスタート
      • コード実行時にコンテナ作成して実行環境を初期化、コードを実行する。
    • ウォームスタート
      • コンテナ作成を省略してコードを実行する。
  • Lambdaが起動した時刻を利用して処理を行うコードを書いていた時のこと
    • handler関数に名言と時刻をセットにしたレスポンスを作成。
    • main関数にはタイムゾーンと時刻を初期化するコードを記述。
    • 1回目は成功したが、2回目以降のタイムスタンプがズレてきた。
  • ウォームスタートの本当の意味
    • ウォームスタートの時は、ハンドラ関数のみしか実行されない。
      • 時刻初期化をハンドラ関数の中で行うように修正したら解決。
  • なぜmainとハンドラに分かれているのか
    • ウォームスタート時の実行有無
      • ハンドラ関数にはスタート方式によらずに実行する処理を記述
      • main関数にはコールドスタートのみ実行する処理を記述
  • まとめ
    • Lambdaという実行インフラは、アプリ側のコードと密接に関わっている。
    • Lambda環境の動きとLambdaに乗せたコードの動きを関連付けて身に付けるのが大事。

資料

speakerdeck.com

最後に

ISUCONの話を聴いて興味が湧きました。Webアプリ開発経験ない人でも太刀打ちできるのか不安です(汗)

Lambdaの話が今日は多めでしたが、ウォームスタートとコールドスタートについては知識上でしか抑えていなかったため、実際にコードを実行させた結果を聴けて勉強になりました。 コード書いて実際に実行してみないと本当に理解できない部分もありますね。やっぱり、触って学ぶの大事!下手でも少しコード書いてLambdaで動かしてみよう。

来月はまた登壇させていただきます。まだほとんど準備できていないからそろそろペース上げていかねば!

jawsug-asa.connpass.com

JAWS-UG朝会 #33 参加レポート

5/10 JAWS-UG朝会 #33 の参加レポートです。今回は久々に登壇もしました(自分の登壇については別途書けたら書きます)。他の登壇者の方々のお話についてレポートを書きます。

目次

イベントページ

jawsug-asa.connpass.com

セッション

セッション② RDSがIPv6をサポートしたため調査・検証してみた  クラスメソッド株式会社 たかくにさん

LTに至った経緯

  • RDSでIPv6をサポートした。
  • パブリックアクセスの設定値について気になった。
    • IPv6はパブリックIPだけど有効化するの?
  • アクセス経路について
    • インターネットを経由しない構成を取るにはどうすればいいのか?

RDSパブリックアクセスについて調査してみた

  • Auroraはサポートしていない。
  • IPv6のみのRDSはサポートされていない(デュアルスタックモード必須)
  • 旧世代インスタンスはサポートされていない。
  • インスタンスタイプ・DBエンジンバージョンごとにサポート状況が異なる。
  • パブリックアクセスとIPv6サポートはどちらかのみ有効化可能。
    • パブリックアクセス有効かつデュアルスタックモードで起動するとエラーになる。
  • 設定変更時はダウンタイムが発生する可能性がある。
    • 入念な検証が必要。

資料

※公開されたら追記します。

LT① DataSyncの構築/運用時に気づいたこと クラスメソッド株式会社 あしさん

AWS DataSyncとは?

  • オンプレミスからAWSストレージサービス、またはストレージサービス間のデータ転送を簡単に実行できるサービス
    • 高速データ転送
    • 簡単な操作性
    • セキュアで高信頼な通信
    • 低コスト

類似サービスとの使い分け

  • DataSync
    • オンラインで大量ファイルを移動
  • Snowball Edge
    • オフラインで大量のファイルを移動
  • Storage Gateway

運用してみてわかったこと

  • タスク実行が失敗しても通知されないことがある。
  • タスクの成功で通知させるかそのままにするか?
    • 通知設定はそのままにして、エージェント異常のパターンは別途エージェントのステータスでの監視でカバーした。

資料

speakerdeck.com

LT② AWSの基礎を学ぼうで学んだ9種類のDBを勝手にふりかえる 98lerrさん

RDB

  • RDS・Aurora
    • 最近はRDS Custom、Aurora Serverless v2も登場
    • RDBを使いたいならばこれ。

Key Value Store

  • DynamoDB
    • プライマリキーのあるJSON風のデータ
    • 2018年以降はオンデマンドモードが利用可能
  • DocumentDB
    • MongoDB互換
    • 任意のキーで検索するのに強い
  • Keyspaces
  • ElastiCache
    • インメモリの高速キーバリューストア
    • 一時保存(キャッシュ)前提
  • MemoryDB
    • 高耐久性とバックアップリストアを備えたRedis

その他

  • Neptune
    • グラフDB
    • RDBのリレーションで対応しきれない複雑な関係を扱える。
  • Timestream
    • 時系列データに特化したDB
    • 時間に特化
  • QLDB
    • 意図しない変更がないことを保証する台帳DB

資料

speakerdeck.com

LT③ 秒でできるコスト異常検出(Cost Anomaly Detection) emiさん

  • 機械学習を使用してコストをモニタリングし、突発的な利用料増加など普段発生しない異常な支出を検出する機能
  • Budgetsとの違い
    • Budgetsは予め設定した予算額に対し、累積利用料金がしきい値を超えた場合に通知する。
  • 請求書が来る月末より前に異常な料金増加に気付くことができる。

①コスト異常検出側の機械学習で検出される異常値

  • コスト異常検出は、アカウントの平均利用料金や利用状況を見ているため、いつ異常値として検出されるのかはユーザは意識しない。
    • 突発的にS3の利用料金が増えた
    • 普段使っていないリージョンで利用料金が発生した等

②通知するためのしきい値設定

  • 検出された異常値を通知するかは、ユーザ側で通知のしきい値を設定できる。
    • 突発的な利用料が増えても、別途設定するしきい値を超えたら通知する。
  • Chatbotを利用したSlack通知も可能

資料

speakerdeck.com

最後に

データベースのお話が2つあったので、データベース勉強中の自分には刺さる内容でした。今なおデータベース何もわかっていないので、勉強の速度を速めたくなりました。 98lerrさんのグラレコでの表現は分かりやすかったです。自分は絵が苦手なので、絵で表現できる人はホント素晴らしいと思います!!そういえば、「AWSの基礎を学ぼう」にも何度も参加してきたのに、アウトプットを一度もしていないことに気付きました。自分の登壇でアウトプット大事と言っておきながら、まだまだだなと反省しました(汗)

コスト異常検出については自分も分かっていなかったので、勉強も兼ねて設定しようと思いました。個人でライトな利用だと検出しづらそうではありますが、個人アカウントで色々やるようになりましたし、意図せず笑えないことが起こらないように予防設定しておきます!!

以上です!自分の登壇については別途書けたら書こうと思います。

JAWS-UG朝会 #32 参加レポート

4/11 JAWS-UG朝会 #32 の参加レポートです。

目次

イベントページ

jawsug-asa.connpass.com

セッション

セッション① Aurora MySQL v1→v3の移行を準備する hmatsu47(まつ)さん

  • Aurora MySQL v1(5.6互換)のEoLが発表
  • 2023/2/28までにv2またはv3への移行が必要
  • せっかく移行するならばv3に

Aurora MySQL v1(5.6互換)のEoLまでの流れ

Aurora MySQL v2のEoLは?

  • 現時点の予定は2024/2/29(延長される可能性はある)
  • 本家のMySQL5.7のEoLは、2023/10/21

Aurora MySQL v3

  • ベースはMySQL8.0
  • 他のRDBMSと遜色ないレベルのSQL文をサポート
    • 複雑な処理は苦手だったが、バージョンを重ねるごとに改善
  • 並列処理性能が向上

v1からの移行の難しさ

  • v2以降に廃止された機能がある
    • クエリキャッシュは良し
    • 古い暗号化関数の廃止
    • MySQL独自文法の廃止
    • GIS機能リニューアルによる非互換
  • リリースモデルの変更
    • コミュニティ版MySQL8.0のリリースモデルを変更し、継続提供モデルを採用することになった。
      • マイナーバージョンもそれに追随することになる。
    • 予約後の追加
      • テーブル名やカラム名にバッティングすると不具合になる可能性がある。
    • 挙動が変更される機能・SQL文の存在
      • GROUP BY ~ ASC/DESC および暗黙ソート廃止
  • 移行パスや移行条件に制限がある
    • v1 からv3は直接アップグレードできない
      • クローンなどで一旦v2に
      • v2からv3へのアップグレードは、今のところスナップショットからの復元一択
      • 現状ではGlobal Databaseをv3に移行するのが困難
    • バックトラック使用中のクラスタはNG
  • コードが大きく書き換えられている
    • 同じSQLでもバージョンによって仕様に変更が入っている
      • 性能低下が発生する恐れがある。

結局のところ

  • 事前調査は大事
  • 設定やアプリケーション変更はほぼ発生すると思った方がよい
  • 動作検証は性能検証は必要
  • 必要な情報をZennの本にまとめてみた

資料

speakerdeck.com

zenn.dev

セッション② IT素人だった私がAWSを触り始めたきっかけとその後 近藤恭平さん

AWSを触ったきっかけ

  • 中高生向けにキャリア情報を発信するメディアを作りたかった
  • AWSをつかったらできるんじゃないのか?と思い、ストリーミングファイルに変換するフローを作った。
    • S3→Lambda→Elemental MedhiaConvert(動画変換したファイルをS3に格納)

Amplify でWebアプリをホスト

  • 素人でも簡単にWebアプリを開発したい
    • AmplifyとVueを採用
    • 数クリックで簡単に環境を整えることができる
    • アクセスエンドポイントも発行される
    • クイズアプリを作って公開

UI Library(Amplify Studio)がすごい

まとめ

  • AWSを利用してWebアプリ開発・発信ができた
  • Amplifyを使えば比較的簡単に環境を整えられる。
  • UI Library の出現で、UIデザインとフロントエンドの境界線があいまいにある未来になるのでは?

資料

※公開され次第追記

LT① AWS WAFを入れたあとのちょっとしたトラブル かなかさん

  • 年末年始のアラート対応を絶対にしたくない!
  • アラートの原因は海外のBotからのDoS的なアクセス
  • 今までは、アラート→サーバログを見る→攻撃者のIPを拒否するConfigを追加してたがキツイ
  • AWS WAFを知って導入
    • 検証環境に入れてもアクセスパターン違うので、本番環境に入れた。
    • 使えそうなAWSマネジメントルール等を有効にしたら爆発した。

アラートの嵐

  • WAFデプロイ後、外形監視(ホスティング)からのアラートが多数発生。

まさかの課金

  • デイリーコストが増えた。
  • S3にVPCフローログ等のログを送る時に発生するコストが増えた
    • ブロックログのみ送ることに変更

アスキーアートを投稿できない

WAFを入れてみて

  • 年末年始のアラートはほぼ0だった
  • WAFはいいものだけど導入は慎重に

資料

※公開され次第追記

LT② TerraformでAWS環境を構築する際のハマりどころ アイレット株式会社 黒野雄稀さん

IAM編

  • destroyの実行
    • Teraformで作ったポリシはデタッチされる(想定内)
    • コンソールで作ったRoleもデタッチされる(想定外)
  • どうすればよかったのか?
    • aws_iam_role_policy_attachmentを使う
      • iam_policy_attachmentでは他のメカニズムを介してアタッチされたポリシが取り消される恐れがある。
        • 既に使っている場合は
          • terraform state rmを実行してtfstateの対象から外す
          • aws_iam_role_policy_attachmentに修正して再デプロイ

まとめ

  • 公式ドキュメントをちゃんと読もう
  • Terraformを使用して本番環境を作成する場合は、知見のある人と一緒にやること
  • ハマりどころもあるが、便利で楽しいので使ってほしい!

資料

speakerdeck.com

LT③ Amazon SNS からのメールをFirehoseとLambdaでまとめる shimoさん

動機

  • SNSでエラー通知が大量に来すぎ
  • SNSがアップデートされていたのを知らなかったので使ってみたい

やってみた① SNSKinesis Firehose→S3 trigger→Lambda

  • SNSを集約できる。ただし間隔は最大15分(Firehoseの制限)
  • S3に置かれたらS3 triggerでLambdaを呼ぶ
  • LambdaがS3からオブジェクトを取り出してSNSデータを整理し、別のSNSで送る。
    • 15分間隔を改善したい。

やってみた② EventBridgeでLambdaをクーロントリガする

  • 時間単位で自由にスケジュールできる。
  • EventBridgeがLambdaをトリガする。
  • Lambdaが未処理のデータを取得してLambdaでまとめて送信。
    • JSONデータからPythonで抽出する。集約して別SNSで送信

資料

speakerdeck.com

LT④ CI/CDわかってる風を装ってたけど、Codeシリーズでちゃんと再入門してみる KDDI 御田 稔さん

背景

  • 最近はCI/CDで開発する前提で話が進みがちだけど、手間とコストをかけてCI/CDを導入する価値を知っておこう

CI/CDが分かりづらい理由

  • オンプレ時代のリリースって具体的にどんな作業やってたの?というのが、インフラエンジニアからはイメージしづらい。
    • こまったら手を動かせ!

Hands-on for Beginnersをやってみた

  • AWS CodeCommit
    • AWS版のGitHub
    • 権限は設定しやすそう
  • CodeBuild
    • 開発者に代わってビルドとテストをする
    • 実行内容はbuildspec.yml に書く。
  • CodeDeploy
  • CodePipeline

    • CI/CDの各段階をひとつながりのジョブとして管理。
  • 修正したHTMLファイルをgit push したら、自動検知されてWebコンテンツに反映されたことを体験できた。

まとめ

  • CI/CDで開発からリリースが楽になる。
  • イメージできない人はハンズオンをやって手を動かそう。
  • CodeシリーズはAWSとの親和性が高いと思う。

資料

speakerdeck.com

最後に

近藤さんのやりたいことを実現するためにAWSを使い始めた話を聞いて、行動力とアウトプットの早さに驚きでした。shimoさんのアップデートを試しながら困りごとを解決した話、御田さんの手を動かして学んだことのアウトプット、このような経験を積み重ねることはスキルアップのためには大事だと思います。勉強だけしても実践の場が足りずなかなか動けていない。自分もスキルアップのためには、四の五の言わずとにかくまずはやってみよう!

来月登壇が決まってますが、まだネタ決まってないからとにかく手を動かして学んだり作ったりして、その成果を発表できるように考えてみようと思います。去年は結構やれてたのに、ホント今年入ってからやれてない。質も大事だけど、まずは行動しよう。

Fin-JAWS 第25回 ~Go to Fin-JAWS School! 2022~ 参加レポート

3/24、Fin-JAWS 第25回 ~Go to Fin-JAWS School! 2022~に参加しましたので、参加レポートを書きます。

※もし資料やアーカイブが公開されたら再度視聴し、間違いなどありましたら修正します。ひとまず公開します。

目次

イベントページ

fin-jaws.connpass.com

アーカイブ

www.youtube.com

セッション

AWS認定試験に向けての準備 山下の場合』 トレノケート株式会社 AWS認定インストラクター(AAI Champion) 山下 光洋さん

  • 先に公式のコンテンツ(ガイド、サンプル問題、模擬試験、Exam Readiness)を取り組むのがおススメ。それから参考書を見る。
  • 一番最初に模擬試験を受けて現状を把握してから勉強している。
  • マネコンを見るのがおススメ。
    • パラメータ設定項目の横にある?をみて理解を深めている。

第4回 愛がゆく。金融機関のラボ訪問 『FINOLAB』 FINOLAB 伊藤 千恵さん FINOLAB 立花 千香さん AWS 飯田 哲夫さん Fin-JAWS 早川 愛さん Fin-JAWS 南 達也さん

  • FINOLABはFinJAWS発祥の地
  • FinTechを創出したい人たちのためのコミュニティの場
  • スタートアップや起業への支援
    • 協業先探しなど
  • イノベーション人材の育成
  • セキュリティやFISC安全対策基準について
  • FINOLABやスタートアップ企業へのサポート

AWS認定の中でも高難易度と噂のネットワーク試験で差をつける!』 試験で差をつける!』 Fin-JAWS 運営 早川 愛さん

  • 認定を取得すると
    • 勉強したことが実務に活かせる。
    • 知識の体系的な整理ができる。
    • バッジを並べてスキルを証明できる。
  • 専門知識認定とは
    • 特定分野のスキル習熟度を証明する資格
  • ネットワーク専門知識認定を目指す理由

    • ネットワークアーキテクチャの設計はシステムの肝心要の部分。
    • 多くのシステムで他システムとのネットワーク接続の検討が必要。
    • オンプレミスでも培ったネットワーク知識を活用できる。
  • 試験対策

    • BlackBelt
    • AWS Skill Builder "Exam Readiness"シリーズ
  • ネットワーク試験の難しさ
    • オンプレミスとのハイブリッド接続は気軽に試せない
      • Direct Connect は高額。
      • VPNは専用のオンプレミス環境が必要。
      • 模擬試験がない。
  • 重点対策ポイント
    • Direct Connect
      • パブリックVIF、プライベートVIF、冗長構成、通信要件、BGP
    • VPN
      • DirectConnectとの併用
    • ロードバランサーの使い分け
      • CLB/ALB/NLBによる機能の違い、使い分けを理解しておくこと。
    • セキュリティ対策サービスは概要を理解しておく。
  • 新バージョンの情報
    • 2022年7月から現行バージョンは使用停止予定
    • Transit Gateway やアカウント間のリソース共有(RAM)などマルチアカウント環境を前提とした問題が出てくると思われる。
  • 試験にとりあえず申し込むのがおすすめ
    • 期限が決まれば嫌でも勉強する。

意志薄弱なアプリエンジニアが挑むAWS全冠』 Fin-JAWS 運営 米澤 拓也さん

  • AWS学習のキッカケ
    • 認定者ラウンジに入りたい!
    • EC2以外のAWSサービスも知りたかった
    • 自身のスキル・市場価値向上
  • 学習モチベーション

    • とりあえずアプリを一本作ってみた。
    • 座学で学んだAWSサービスをどんどんアプリに取り込んでみる。
    • 使えるサービスが増えると楽しくなる。
  • 勉強方法

    • 座学と実機で勉強した。内容がアプリよりだったので面白く感じるようになった。
    • SAP(ソリューションアーキテクトプロフェッショナル)は問題文が長文なので読解力をつけつつ、細かいパラメータなどを実機を触って確認。
    • SAA(ソリューションアーキテクトアソシエイト)とSAPが大事。Specialityの認定試験は、この2つが身に付いていれば一気にハードルが下がる。
  • いいこと

    • チャンスが広がった。
    • 強い上司の言っていることが理解できるようになった。
    • システムを組む際のプラクティスが学べる。
    • 市場価値が爆上りした。
  • まとめ

    • 資格学習を通して「AWSの使い方」以上のことが学べる。
    • チャンスが舞い込んでくる。
    • とりあえず動かしてみる」を強くおススメ。

最後に

参考書は体系的にまとめられていて勉強しやすいため、これまでの認定試験では参考書の比重を高くして勉強をしていました。公式コンテンツにも触れていましたが、今思うと比重は低かったなと…『AWS認定』なのだからそれだけで終わらずに、公式のコンテンツと実サービスに触れないと理解は深まらないなと改めて思い知りました。もっとAWS公式コンテンツを活用しないと損ですね。次はSOA(SysOps Administrator アソシエイト)とSAPの受験を考えていますので、今回の学びを基に勉強に取り組みます。

ANS(高度なネットワーキング専門知識)もバージョンアップ前に受けたいけど…圧倒的に実践が足りていない…SAPの勉強中にいつ受験するか考えますが、いずれは挑戦したいです!