amareloのブログ(仮)

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

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

はじめに

1/17 JAWS-UG朝会 #41 に参加しましたので、まとめを書きます。

目次

セッション① RDS/Auroraバージョンアップのポイント hmatsu47(まつ)さん

自分はデータベースのバージョンアップをしたことはないですが、ポイントを抑えることができる内容で分かりやすかったです。 やはりデータベースのバージョンアップや移行は考えることが多くて大変と思いますし、DBを担当されている方々には頭が上がらない思いです。

データ移行時の考慮ポイント

重視するポイントはバージョンアップ対象ごとに異なる。v1からv3へのバージョンアップは避ける。

  • ①データ完全性
  • ②機能の互換性
    • バージョンアップ前後で動作する仕様に
  • ③性能
    • オプティマイザヒントの使い方は事前に調べておくこと
    • 事前の性能テストは重要
  • ④停止時間
  • ⑤切り戻し

手法

  • ①インプレースアップグレード
    • 既存DBとクラスタをそのままバージョンアップ
  • ②クローン後にインプレースアップグレード
  • ③ブルーグリーンデプロイ
    • 旧バージョンのDBからコピーしたDBをアップグレードし、旧DBから新DB間レプリケーションする。
    • データ不整合の可能性がある。
    • PosgreSQL系の場合は論理レプリケーションのためDDLがほぼ使えない。
  • ④アプリケーションを改修後新旧DBへの同時並行書き込み
    • 無停止でバージョンアップが実現可能だが、アプリケーション実装の手間がかかる。
    • 書き込み処理時間が延びる。

計画進行のポイント

組織体制やバージョンアップ対象に適した計画を。

  • ①作業分担と協力体制
  • ②情報共有
    • フィードバックを集めて生かす。理解可能な形で共有。
  • ③事前準備
    • リハーサルを何度も実施すること。一度では気づかないバグもある。

資料

speakerdeck.com

セッション② EC2にてDisk枯渇が発生した場合に何が起きるのかと対応方法 ハンズラボ株式会社 中川皓紘さん

個人でAWSを使っているだけだとディスク枯渇のことあまり考えないけど、 業務で使う場合は考えないとならないですね。よい気づきになりましたし面白かったです! 自分もちょっと試してみようと思いました。

障害対応フローを再現

  • Disk枯渇状態にする。
  • 再起動して起動不可になることを確認(セッションマネージャで接続できない)
  • Disk枯渇状態のEC2からEBSをデタッチして、復旧用EC2にアタッチして起動する。
  • 新規でアタッチしたEBSはマウントされていないので、マウントする必要がある。
    • DiskのUUIDが重複してマウント不可になるが、一時的なマウントなのでUUIDの競合を無視してマウントする。
  • ファイル削除して残容量が危険域を脱したらもとのEC2に再度アタッチする。

  • Amazon Linux2の場合はディスク拡張しても、パーティションをコマンドで作らなければならない。

資料

speakerdeck.com

LT① Amazon Forecast を使って売上予測をしてみた 株式会社モリサワ 小室貴史さん

AL/MLのサービスはまだまだ勉強不足なので、やってみた内容のLTは全体感を知れて有り難いです。 自分がコーヒー売ることになったら使ってみたいなw

  • Amazon Forecastはマネージドな時系列なデータ予測サービス
  • データセットが準備されているのでAL/MLを知らなくても使えるが、用語を調べたり専門的知識はあった方が良い。
  • 売り上げ予測で試してみる。
    • DBかCSV取得しS3に保管。Forcastで分析してQuickSightで可視化した。
    • 休日データがノイズになって予測にズレが出た。
  • データ量が少ないといい結果が出てこない。
  • 費用はそこそこかかる。

資料

speakerdeck.com

LT② 統合CloudWatchエージェントとCloudWatch Logs エージェントの違いを深掘ってみた クラスメソッド株式会社 おつまみさん

CloudWatch エージェントは「統合CloudWatchエージェント」の方しか知らなかったです。 旧があったことも初めて知れて、新旧を比較することでバージョンアップで便利になって今があることを再認識出来て良かったです。

  • CloudWatchエージェントとは?
    • EC2からログやメトリックスを収集するためのエージェント
  • CloudWatch Logs エージェント
    • 廃止予定
    • ログのみ収集
      • メトリックスはカスタムスクリプトでCloudWatchにアップロードする必要がある。
    • Linux系のみでオンプレ未対応
  • 統合CloudWatch エージェント
    • ログとメトリクスを収集
    • 複数プラットフォームに対応可能。オンプレも対応。
    • SystemsManagerによる設定が可能。

資料

dev.classmethod.jp

LT③ Transit Gateway(TGW)利用時における専用サブネットの必要性 積田 優生さん

去年Transit Gatewayのハンズオンをやった時は、ENIとEC2別々のサブネットになっていました。 公式ハンズオンでバットプラクティスにすることはないとはいえ、なぜそうなっているのかは意識していませんでした。 その意味を知れてできてよかったですし、ハンズオンの構成もなぜこうしているのかを意識することで学びの質が変わると実感しました。

  • Transit Gateway ENIとEC2を同じサブネットに置く(バットプラクティス)
    • EC2は、配置されたTransit Gatewayサブネットのルートテーブルを参照する。
      • EC2の意図するルートテーブルが作れなくなるため、EC2から直接アクセスさせたい先へのルートを通せなくなる。
        • /24でネットワーク設計していた場合は、IPアドレスが無駄になってしまう。
  • Transit Gateway ENI専用サブネットを作成し、EC2は別のサブネットに置く(ベストプラクティス)
  • 必須ではないが、影響を理解していないのであれば、TGWアタッチメント専用サブネットを作った方が良い。

資料

speakerdeck.com

zenn.dev

最後に

今年はじめの朝会、新たな学びと気づきがあって濃い内容でした。 それにしても、ラジオ体操を毎月やるたびに肩の鳴りが増えている気がする…