JAWS-UG近畿・中国レポート 第2回

バッドノウハウもしっかり学べるコミュニティならではの内容

そんな使い方あかん！やらかした事例満載のJAWS-UG大阪

AWSアカウントを作ったらまずやることって？（森さん）

　JAWS-UGコアメンバーである森大樹さんは、AWSアカウントを作ったらやらなければならないことを説明した。

神戸からの移動で遅刻した森大樹さんは安定のすべらないLT

　森さんはAWSユーザーに安全なアクセス制御を提供するIAM（Identity and Access Management）について説明する。基本的にはAWSを利用する人専用のアカウントを作成し、利用するリソースを設定。あとはAWSリソースをどのような方法で利用するかを決めればよい。「誤ってインスタンスを消してしまったり、セキュリティグループのポートを間違えて設定してしまうとか。あるいはAWSアカウントを乗っ取られ、別のリージョンでインスタンスが起動したり、ハイスペックのインスタンスを立てられて、高額な請求が来ることがある」と森さんは指摘する。高額請求が来たら、不要なリソースを削除し、請求の免除を申請しなければならないので、IAMの設定は必須になる。

　AWSのドキュメントにも書かれていることだが、IAMを導入する際にはまずなんでもできてしまうルートアカウントのアクセスキーを削除する。次に二要素認証を導入して、ログイン時のセキュリティを高めることも重要。

Access Keyの削除や二要素認証の導入でアカウントを守ろう

　また、最小限の権限だけを付与したIAMユーザーやグループを作成したり、CloudWatchを使ったBillingAlertの設定、全リージョンのログを収集するCloudTrailをオンにしておくことも必要になるという。その他、パスワードポリシーの厳格化やTrusted Advisorのチェックなども定期的に行なうべきだという。森さんは「守るのは自分。やっていない方をすぐにやってもらいたい」と述べて、LTを締めた。

EBSとAuroraでごっつはまるポイントは？（小林さん）

　本編最後のLTはサーバーワークスの小林考剛さんによる「ストレージのごっつはまるポイント」。ぞくぞくするようなEBSとAuroraの3つのバッドケースを披露した。

中央電力でポケモンGOをやろうと思ったらiPhoneのGPSが使えなくなったという小林考剛さん

　まずEBSの初期化。EBSの場合、スナップショットからボリュームを復元すると初期化が必要になるが、初期化後にパフォーマンスが著しく劣化するという問題にあたるという。「S3にある14TBのボリュームをリカバリしたところ、本来320MB/sくらい出る予定が、50MB/sしか出ない。28万秒なので、70時間くらい必要になる」（小林さん）とのことで、災害復旧の場合は注意が必要。スナップショットから復帰後、バックグランドで時間をかけて読み込まれるため、対応策としては、あらかじめ時間を見計らっておくか、アクティブ／アクティブの構成を準備しておく必要があるという。

　次はEBSでのMBR・GPT事件。当初2TiBで運用していたWindowsのファイルサーバーの容量を増やそうとした際に、2TiB以上が読み込まれないという問題だ。スナップショットを作り、EBSを作って、アタッチするという手段は間違っていない。しかし、2TiB以下のWindowsサーバーをEC2で起動すると、無条件にMBRでフォーマットされるため、スナップショットから復元する場合も2TiBしか認識しない。そのため、EBSはEC2起動後にアタッチし、その後2TiB以上を扱えるGPTでフォーマットするのがよいという。

2TiB以上をサポートしていないMBRと2TiB以上のGPTでの違いに注意

　最後はAuroraのレスポンス問題。ある案件でAuroraの性能が著しく悪化し、接続エラーが頻発したため、いったんインスタンスの再起動を行なった。しかし、40分経ってもアベイラブルにならなかったという。小林さんが調べたところ、これはAuroraのログ格納領域にあたるFree Local Storageが少なくなったことに起因する。ここは自動拡張せず、インスタンスの種類ごとにサイズが異なる。そのため、General LogやSlow Query Logなどが溜まらないようにしたり、分析の際にファイルとして出力して、ストレージを消費しない工夫が必要がある。小林さんは「AWSはとにかく便利だが、はまって初めてわかることも多い。バッドノウハウもどんどん共有しましょう」と語って、LTを締めた。