amareloのブログ(仮)

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

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の勉強中にいつ受験するか考えますが、いずれは挑戦したいです!

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

3/14 JAWS-UG朝会 #31 に参加しました。久々に参加レポートを書きます。

目次

イベントページ

jawsug-asa.connpass.com

セッション内容

セッション① Amazon Linux 2022をさわってみた 株式会社サーバーワークス 小倉大さん

Amazon Linux 2022とは

  • 現時点ではプレビュー版。
  • Amazon Linux 2 の後継バージョンOS(2023年6月30日で長期サポートが切れる)
  • 5年の長期サポート
    • 最初の2年はアクティブな開発フェーズ。後の3年はメンテナンスフェーズ。

Amazon Linux 2との違い

  • SSM Agentがデフォルトで入っていない
    • 手動インストールが必要
    • EC2作成時にインターネットへ疎通できるようにする必要がある。
      • S3へSSM Agentのパッケージを取りに行く。
      • セッションマネージャーでログインする時にSystems Managerへアクセスする。
  • SE Linux がデフォルトで有効
    • パッケージ管理がdnf
      • yum の後継コマンドでオプションは一緒
      • 今のところyumも使える。
      • Amazon Linux Extras が使えない。
  • SSH接続がデフォルトでRSA無効
    • キーペアタイプをED25519にする。
    • RSAで接続するには
      • sshd_configに追加
      • ターミナルにrsa_sha2_512を選択

新機能を確認するときのやり方

  • とりあえず手順をあまり見ないでマネコンを触り、詰まったら調べて対応する。
  • これの繰り返しをして、詰まったところを調べた方が覚えやすい。

資料

www.slideshare.net

セッション② インプレースデプロイからBlue/Greenデプロイへの変更をゴリ押しで進めた話 株式会社サーバーワークス 古川敏光さん

既存環境

  • 複数の環境がFargate上で稼働している。
  • Internal ALBによるサービス間通信。
  • ECSはローリングアップデート
  • EC2上にJenkinsを構築

BGデプロイ実装方法

  • ターゲットグループの直接切り替え
    • NLBの後段にInternalALBを設置
    • AWS CLIを使用してNLBのターゲットグループを直接切り替える。
    • 実装コストを第一優先に考えると望ましかった。

懸念点

  • サービス間のアクセスをどうするか?
    • ALBの後にNginxを配置してURLでリバースプロキシ先を切り替える。
    • Fargate上にNginxを構築して、各ECSコンテナに自動でAレコード登録をする。

ゴリ押しポイント

  • 既存テンプレートを使いたいので、ServerlessFrameworkを使う。
  • ターゲットグループ1つに対して、関連付けられるリスナールールは1つのみ。
    • ターゲットグループとリスナールールの関連付けを自ら行う必要がある。

まとめ

  • BGデプロイ手法に正解はない。
  • 実装コストやダウンタイム許容時間など、要件に沿ってデプロイ手法を決める。
  • Codeシリーズの方がCI/CDの実装コストは小さいが、Jenkinsの方が細かいジョブを設定できる。

資料

speakerdeck.com

LT① AssumePolicyの意外なハマりどころ 崎原晴香さん

今回実現したいこと

  • とあるAssumeRoleの権限移譲先として、あるグループに属しているIAMユーザ全員を指定したいケースを考える。
  • しかし、IAMユーザグループをAssumePolicyのプリンシパルに指定することはできない。

解決策

  • TerraformのDataSourceを利用
    • IAMグループに属するIAMユーザ情報をリスト形式で得ることができる。
    • 所属ユーザARN一覧をfor文で取り出してAssumePolicyのプリンシパルに指定することができる。
      • グループに新しくユーザが追加されても、追加ユーザのARNをプリンシパルに追加するところまで自動化することができる。

資料

speakerdeck.com

LT② DirectConnectGatewayの罠!? 株式会社ターン・アンド・フロンティア 坂下朱紀さん

DirectConnectGatewayとは

  • DirectConnectのAWS側の受け口の一つ
    • ない場合はVPCごとにVIFが必要。
      • ルータ設定が必要など
    • あると拡張性がある
      • VPCとの共有もできる。
      • ルータ設定も不要

構成変更で分かったこと

  • DirectConnectを冗長化してActive-Active構成にすると、戻りの通信が異なる経路になってしまう。
  • VGWは複数のDXGWに紐づけられない。
  • DirectConnectGatewayを使わずDirectConnectを冗長化した。

資料

www.slideshare.net

LT③ 漏洩しても大丈夫なクレデンシャル運用ができないか考えてみた 株式会社ゲームエイト 岩佐海彦さん

やらかし防衛策を並べてみたらIP制限したくなった

  • リーク先のリモートからではなく端末上で叩かれるのは防げない。

可変IP、複数IPでも使える基盤を考える

  • 未許可のIPからでも許可申請を受け付ける必要がある。
    • 踏み台IAMユーザを作る
    • 踏み台ユーザはMFA必須。かつキャッシュしないようにする。
  • 複数IPでも利用できるようにするには
    • 申請日時を管理して一定時間ずつIPを貯める。
      • DynamoDBにてTTL(Time To Live)管理をする。
        • TTL設定することで自然消滅してくれる。

IAMの権限を書き換える権限の注意

資料

speakerdeck.com

LT④ AZ間レイテンシを比較してみた 積田 優生さん

前提知識

  • リージョン
  • アベイラビリティゾーン(AZ)
    • 複数のデータセンタによって構成された耐障害性を意識した設計を採用
      • どのリージョンも2つ以上のAZで構成されている。
      • AZは1つ以上のDCから構成されている。
  • AZ名とAZ IDについて
    • AZ名は各AWSアカウント個別に割り当てられるため、AZ名とAZ IDの対応が違う場合がある。
    • データ転送量やレイテンシーの観点から、AWSアカウントをまたいで同一のAZを利用したい場合は、AZ IDにてAZの認識を合わせる必要がある。

レイテンシ(ラウンドトリップ)測定概要

  • 東京リージョンと大阪リージョンのAZ間レイテンシを測定
  • 各サブネットにEC2(m5.large)を1台ずつ作成

測定結果

  • 単一のAZのみを利用する場合、同一AZ内でレイテンシの差はどのAZでもほとんどない。
  • 大阪リージョンのAZ間レイテンシが想定以上に低かった。
    • AZ間でのレイテンシ要件が厳しい場合は、大阪リージョンを利用するのも1つのオプション

資料

speakerdeck.com

所見

リージョンとアベイラビリティゾーンについては意識しないと忘れることが多そうなので、今回の朝会で見直そうと思いました。

認証認可の管理方法も環境によってさまざまな実現方法があるんだと思い、奥の深さを感じることができました。

サービスや実装方法の深掘り、とりあえず触ってみることもあまりできていないので、もっと研究してみたくなりました。

最後に

2022年一発目の記事でした。年が明けてから勉強会に参加していたものの、ブログレポートは何か書く気が起きず…それ以外のネタも書けず…書こうと思っても書けませんでした。

最近勉強会に参加してても散漫になっていると思い、今日はブログ書く前提で参加しました。その意識があるだけで、発表の聞く集中力が全然違いました。今後もなるべくアウトプット前提で勉強会に参加していこうと思います。

ブログ休んでたのはちょっと思うところがあってなので、その辺は書けたら書こうと思います。

JAWS-UG 初心者支部#40 年忘れLT大会!! 参加レポート

はじめに

12/27 JAWS-UG 初心者支部#40 年忘れLT大会!!に参加し、登壇してきました。 まずは登壇者皆さんのお話のまとめをしてから、自分の登壇の振り返りをしたいと思います。

イベントページ

jawsug-bgnr.connpass.com

LTの内容

新プロダクト開発でやったこととやり残したこと 小室 貴史様

  • 実施したこと
    • 一人インフラエンジニアは大変なため、持続可能な環境構築を心がけた。
    • 運用の手間をいかに減らすかに注力した。
      • IaC、CDK、Fargate + ALB
  • できなかったこと
    • メトリクス分析、アナリティクス、機械学習はできなかった。

資料

speakerdeck.com

おいでよ!CLI専門支部 emi様

  • CLI専門支部とは

    • CLIを使いこなしたいユーザの集まりでハンズオンメインの活動
    • AWSとどう付き合っていくかを考えて行く場、特に本番環境
    • 別名転職専門支部
  • CLIを勉強すると何が嬉しいのか?

    • CLIを学ぶことでAWSサービスのAPIのほぼすべてを操作できるようになる。
    • APIを理解することでAWSを真に理解することにつながる。
    • 反復再現性が高いので、自動化にも対応しやすい。
  • CLI専門支部の楽しいところ

    • ハンズオン終了後アンケートでワイワイする感じが楽しい。
    • 波田野さんのほどよい鬼畜ワード
  • CLI専門支部への参加条件

    • CLI身に付けたい人ならば、誰でもOK!
    • LINUXの知識があった方が良い。

資料

speakerdeck.com

re:Invent 2021個人的に気になったアップデート 山口 正徳様

  • Well-Architected Framework に持続可能性の柱が追加された。
    • システムのあるべき姿を見つめなおす時が来た。
    • あなたのシステムは、本当にその規模のリソースを必要としているか?を考えなければならない。
    • あなたの顧客は、システムに対し本当にその性能を求めているか?を考えなければならない。
    • AWSを上手く利用することでだけでなく、Sustainabilityについて常にセットで考えなければいけない状況にある。
      • スケールアウトだけでなく、スケールインを実装する。
      • インスタンスタイプを一つ落とすだけでも電力量は変わる。
      • I/Oを求められていない場合は、磁気ディスクを採用する。
        • 磁気ディスクの方が電力量が低い
    • 持続可能性の柱は、簡単なところから適用できる。

資料

speakerdeck.com

aws.amazon.com

ラスベガスで感じたこと AWSJ Kameda様

  • re:Inventの会場はマスクをしていたが、アメリカの町ではしていない人が多かった。
  • アメリカは、コラテラルダメージ(副次的被害)の考えが大きい。
    • プラスの影響とマイナスの影響を合算した考えで行動しており、日本と違って合理性が強い。
  • 印象に残ったアップデート
    • AWS Mainframe Modernization
      • COBOLからJAVAの自動変換
        • ハンズオン環境を作るのにCOBOL環境作れる人いたら連絡ほしい。
    • AWS Migration Hub Refactor Spaces
      • モノリシックなアプリケーションをモダナイズ化させるために、アプリケーションをリファクタリングするための設計を保持するサービス。

ビギナーが、CloudFormationを使ってハマったお話 上地 航平様

  • IaCとは
    • インフラ環境をコードで管理する概念
  • CFnの利用
    • ローカル環境でテンプレートファイルを記述
    • CFnへデプロイ
    • 各種AWSサービスをスタックとして構築
  • テンプレートファイル間で、リソースの関連付けが重要
    • 2層目で記述したSGは、1層目で記述したVPCに所属する
  • エラー文はコンソールの方が見やすい。

資料

speakerdeck.com

AWSちょっと興味ある」人が技術コミュニティでエンジョイするには!?  御田 稔様

  • AWSが少しづつ分かってくるとコミュニティ参加が楽しくなる。
  • すぐ触れる環境があるのは恵まれている。手を動かそう!
  • 初心者向けのハンズオンをやってみよう。
  • アウトプットしろ!!
    • コミュニティ全体の心理的安全性が高まる。
    • 発言が活発になり、インプットがさらに増える。
    • 技術ブログを書いてみる。
    • LTに挑戦してみる
  • 知らないことは当たり前
    • 恥ずかしがっちゃダメ、別に死なないから!
    • 間違うことを恐れていたらアウトプットできない。
  • 技術コミュニティをエンジョイすると
    • 一気に視野が広がる
    • AWSスキルを楽しく伸ばせる
    • 市場価値が上がる

資料

speakerdeck.com

機械学習を教えてもらった事がない初心者がAmazon SageMaker Studio Labを触ってみた 長田 英幸様

  • Amazon SageMaker Studio Lab とは
    • AWSアカウントやクラウドの知識がなくても、誰でも機械学習を学んで実験できる無料サービス
    • 英語のドキュメントしかないが、ブラウザの翻訳機能を活用
    • ブラウザ上で作業が完結するのでとっつきやすい。

資料

speakerdeck.com

機械学習民主化が加速する!re:Invent 2021で発表されたノーコードで機械学習のモデルが作れるサービス、『Sagemaker Canvas』について Takashi Kawamoto様

  • SageMaker Canvasとは
    • ノーコードで機械学習のモデルを作れる新サービス
  • SageMakerとは?
    • Machine Learningサービス
    • たくさんファミリー機能がある
  • SageMaker Canvasの特徴
    • MLの専門知識がなくても使える新設設計
    • 専門用語を用いないように配慮されている
    • AWSコンソールを経由しないシングルサインオン
    • 前処理をあるていど自動的にやってそうだが、欠損値があるとエラーになる。

資料

speakerdeck.com

2021年のJAWS-UGの活動振り返り 沼口 繁様

  • CLI専門支部の勉強会申し込み者数が凄い!勉強会開催回数も一番多い!
  • 初心者支部は登録メンバ数がJAWS-UG支部の中で一番多い。
  • BIG DATA支部がこの1年で一番メンバー増加率が高かった。
  • 新しいことへの興味がわかないと、同じ興味を持つ人とのつながりが広がらない。
    • Self Running User Community の継続が難しくなる。
    • 地域支部の問題だけではない。

資料

www.slideshare.net

自分のLT 「MFAデバイスを無くした時の対応方法」

最後に自分のLTについて触れます。

先日、仮想デバイスとして使っていたiPhoneをMFAデバイス変更せずに機種変した話と、その時の対応方法について話しました。 厳密には「無くした」と思っておりこのタイトルにしましたが、よくよく考えたらタイトルと内容にはズレがあるのでは?と思いました。 タイトル通りMFAデバイス(ハードウェアトークン等)を紛失した時のことを期待していた方もいたかもしれません。 そう思うと、それを期待していた参加者の方々には申し訳ないことをしたと反省しています。

話す内容とタイトルに乖離を生じさせたり、参加者に誤解を与えないよう、以後気をつけなければと思いました。

資料

speakerdeck.com

最後に

思えば、今年最初の登壇が初心者支部での登壇でした。また登壇の機会をいただけて、初心者支部の皆様に感謝いたします。

まだまだ勉強不足ですし、初心者の域を脱していないと思っています。来年もAWSを通じて技術の深掘りをし、一つでも多くアウトプットできるよう励みたいと思いました。

寒くてもアイスコーヒーのすすめ

目次

はじめに

この記事は、Coffee Advent Carendar 2021 第5日目の記事です。

adventar.org

先週から急に寒くなってきましたが、いかがお過ごしでしょうか?

今日は、寒くてもアイスコーヒーを勧めたい!という、季節感まったくない記事を書きます。

寒くてもアイスコーヒーの理由

手軽にコーヒーを飲める

コロナ禍の在宅勤務で、休憩時間中にコーヒー豆を挽いて飲む方も増えたかと思います。 とはいえ、毎日コーヒー豆を挽くのも大変、豆を挽く時間がないという時もきっとあると思います。

そんな時は冷蔵庫にアイスコーヒーを入れておきましょう!!

忙しくても、冷蔵庫に行ってさっと取り出せて、グラスに注げばすぐにコーヒーを味わえるます。

最近、在宅勤務でコーヒーを飲む時間が取れない日も出てくるようになり、コーヒーを飲む時間の確保方法を色々考えていましたが、

アイスコーヒー作っておけば忙しくてもすぐ飲める!!!

と思い、寒くてもアイスコーヒーを作っておき、いつでも飲めるようにしました。これで、忙しくてもコーヒーを飲みたくなった時は、アイスコーヒーを注いで飲んで、すぐに仕事に取り掛かれます。

暖かい部屋で飲むと格別!!

寒くてもアイスコーヒーを飲むようになり、気づいたことです。

暖房器具を使うと部屋も乾燥するし、頭もボーっとすることが増えます。そんな暖かい部屋で冷たいアイスコーヒーを飲むと、シャキッとします! ホットコーヒーよりも喉が潤う感じもしますので、良いと思います。

暖かい部屋やコタツで飲むアイスコーヒーの時間は、至福の時です!!

電気代喰って家計を逼迫しない程度でやってみてくださいw

最後に

コーヒーを柔軟に飲めるようになって、在宅勤務できることに本当に感謝しています。その分、仕事のアウトプットの早さと質は上げなければなと思いました。その在宅勤務をきっかけに、改めてアイスコーヒーの手軽さとありがたさ、楽しみ方を再確認することができました。

今後は、アイスコーヒーとは年中付き合っていくことになりそうです!!