6/7 JAWS-UG朝会#34 に参加しましたので、レポートを書きます。
目次
- 目次
- イベントページ
- セッション・LT
- 最後に
イベントページ
セッション・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
ベンチマーカー
当日の運営
- ベンチマークの不具合事象が発生。
- ファイルディスクリプタの上限を上げようとしたが、Fargateでは設定を変えられないことが判明。
- 一部の異常系でHTTPコネクションの解放処理に不具合
- ベンチマーカーのテストをローカルのDocker環境で実施していた。
- ローカルのDocker環境のファイルディスクリプタは異なり、枯渇することはなかったため。
- 一部の異常系でHTTPコネクションの解放処理に不具合
資料
セッション② スタートアップでどのように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管理を提供
- ガードレール
- 必須ガードレールの例
- Control TowerやCloudFormationで設定されたIAMロールを変更不許可にする
- ログアーカイブの公開読み取りアクセス設定の検出
- 強く推奨
- 選択的ガードレール
Control Tower導入までに行ったこと
- OUの設計
- OUは多層にすることはできない（Organizationsはできたはず）
- 権限設定
- アカウントの所属グループと権限
- グループに所属させるユーザ等
- ルートアカウントの管理方法検討
Control Towerを導入した感想
- 抱えていた仮題を解決できた
- OrganizationsとSSOを用いたマルチアカウント運用がとても簡単に導入できた
- CloudTrailやConfigなどのセキュリティサービスの導入も簡単に出来た。
Control Towerを導入すべきか
- 既にマルチアカウント運用がうまくできている組織
- 導入コストに比べてメリットを享受しづらい
- ガードレールが使える
- 正確なLanding zoneを使うことができる
- まだマルチアカウント運用ができてきない組織
- ぜひControl Towerを導入するべき！！
LT① Lambdaで最近やらかした話 もつさん
- Kinesisから送られてくるデータを抽出して、別のSaaSへのAPI連携をさせるために、Lambdaで実行させようとしていた。
- テストを繰り返していたところ、CloudWatchでは秒単位でエラーログが出続けていた。
- 原因
- 反省
- 想定しない件数が出た時のためにCloudWatchアラートを入れておくべきだった。
- もう少し早めに気づけた可能性があった。
- 複数処理の分散のためにStep Functionsを使うことも考慮しておけばよかった。
- 想定しない件数が出た時のためにCloudWatchアラートを入れておくべきだった。
資料
LT②うわっ…AWSのセキュリティ系サービス、多すぎ…？オンプレエンジニアにも分かりやすく整理してみた KDDI 御田 稔さん
- セキュリティ事故が起こると大問題になるが滅多にないため、正常性バイアスになりがち。
- 何かあった時に一番困るのは責任者で、組織が大きいほど各担当の自分事意識が薄れがち。
AWSとオンプレの違い
- 簡単に全世界から攻撃される。
- セキュリティ知識なしに使うとすぐ事故につながる。
- マネージドサービスの場合は、利用者が気にしなくていい部分が増える。
ネットワークセキュリティはオンプレと似ている
有効化するだけのサービス
- Config
- リソースの変更記録
- Security Hub
- 自アカウントの危険性を把握
- セキュリティ系サービスの出力結果を統合
- GuardDuty
- Security HubとGuard Dutyは30日無料お試し可能。トライアル中に推定コストを出してくれる。
- とりあえず30日使ってみよう。
万が一インシデントが発生した場合
- Amazon Detective
- 被疑リソース周辺の怪しいログを可視化
資料
LT③ アプリ側のコードを書いていた人がLambdaに触れて気づいたこと さき(H.Saki)さん
- main関数とハンドラ関数が別に用意されている。
- ２つのLambdaのスタート方式
- コールドスタート
- コード実行時にコンテナ作成して実行環境を初期化、コードを実行する。
- ウォームスタート
- コンテナ作成を省略してコードを実行する。
- コールドスタート
- Lambdaが起動した時刻を利用して処理を行うコードを書いていた時のこと
- handler関数に名言と時刻をセットにしたレスポンスを作成。
- main関数にはタイムゾーンと時刻を初期化するコードを記述。
- 1回目は成功したが、2回目以降のタイムスタンプがズレてきた。
- ウォームスタートの本当の意味
- ウォームスタートの時は、ハンドラ関数のみしか実行されない。
- 時刻初期化をハンドラ関数の中で行うように修正したら解決。
- ウォームスタートの時は、ハンドラ関数のみしか実行されない。
- なぜmainとハンドラに分かれているのか
- ウォームスタート時の実行有無
- ハンドラ関数にはスタート方式によらずに実行する処理を記述
- main関数にはコールドスタートのみ実行する処理を記述
- ウォームスタート時の実行有無
- まとめ
- Lambdaという実行インフラは、アプリ側のコードと密接に関わっている。
- Lambda環境の動きとLambdaに乗せたコードの動きを関連付けて身に付けるのが大事。
資料
最後に
ISUCONの話を聴いて興味が湧きました。Webアプリ開発経験ない人でも太刀打ちできるのか不安です（汗）
Lambdaの話が今日は多めでしたが、ウォームスタートとコールドスタートについては知識上でしか抑えていなかったため、実際にコードを実行させた結果を聴けて勉強になりました。 コード書いて実際に実行してみないと本当に理解できない部分もありますね。やっぱり、触って学ぶの大事！下手でも少しコード書いてLambdaで動かしてみよう。
来月はまた登壇させていただきます。まだほとんど準備できていないからそろそろペース上げていかねば！
