2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
しくじり3つ目に行く前にちょっと休憩を挟みまして、猫ちゃんの画像で癒されつつ……。ちょっと軽いネタを入れていこうかなと思います。
170万円とまではいかなくても「なんか請求高くない?」ということがあったかなと思います。請求でけっこう高い割合を占めるのは、やっぱりサーバ。EC2の起動している時間の料金ですね。なので節約のために使わないEC2を止めるということをされている方はけっこう多いかなと思っています。
とは言えEC2を停止しているから課金がゼロになるかというとそうでもなくて、EC2で使っているEBSは課金されちゃいますし、停止したインスタンスに関連づくElastic IPもごくわずかながら課金されちゃいます。
例えばEC2を止めていると言っても使っていないEC2がめちゃくちゃ数があって、それによってEBSの合計のボリュームがすごく多くなってしまったりすると、これもちりつもで、結局EBSの料金がめちゃくちゃ高くなるということがあるかなと思います。
止めているんじゃなくて、使わなくなったAMIは消しているのに「なんか高いな」みたいな話があるかなと思います。AMIを消してもEBSのスナップショットは残っちゃいます。スナップショットを消さないと、これもちりつもになって気付いたらスナップショットがめちゃくちゃ溜まっていて、それでお金がかかっていたという話もあるかなと思います。
EBSに関連してということは、RDS系も何か残っているんじゃないかという話なんですけれども、RDSでいくと、手動のスナップショットは自動で削除されなかったりするので、ここもちりつもかなと思います。
ということでちょっと番外編なんですけれども、「EBS 塵も積もれば山となる」ということで、使っていないEBSとかも定期的に整備していければ、ちょっとはコストカットになるのかなと思います。
ではしくじりの3つ目に行こうかなと思います。しくじり3つ目は「Lambda突然の死」というタイトルです。これも詳しく見ていきます。
S3にアップロードしたzipファイルをLambdaで展開して、その展開したファイルを別のS3に保管するというような要件があって、それどおりにアーキテクチャを設計して実装しました。これも最初は景気よく動いていたんですが、あるタイミングでLambdaでエラーが頻発するようになりました。
まずはCloud Watch Logsを見てみると、「No space left on device.」というエラーが出ていました。No space leftということは、「Lambdaが使っているボリュームに容量がもうないよ」ということです。Lambdaのディスク容量ってなんだ? という話ですが、Lambdaは一時的なファイル置き場として/tmpというところが利用可能になっています。
利用用途としては、今回みたいにzipファイルを展開して一時的にファイルを置きたいときに使うかなと思います。この/tmpというディレクトリは容量が512メガバイトしか使えないので、512メガバイト以上のファイルを置こうとすると今回のようにエラーになります。
今回のアーキテクチャ上は、まずS3にzipファイルを置いて、そこからイベントが発行されてLambdaが起動してzipファイルを展開してという流れになっているのですが、その各zipファイルで展開されたファイルというのは512メガバイト以内だったにもかかわらずディスクが枯渇してしまったと。
なんで枯渇してしまったのかという話なんですが、Lambdaの実行環境というのはとてもよく再利用されるというのはドキュメントにも書かれています。これは最後の1文なんですけれども、「Lambda関数を連続して呼び出す場合、AWS Lambdaはできる限り実行コンテキストを再利用します」。
ということで、今回Lambdaが再利用されるということは頭になくて、解凍したファイルをいちいち消していなかったというのが原因になります。zipファイルで展開したファイルを/tmpに置いて、そのままにしていたんですね。Lambdaの実行環境は使い回されちゃうので、どんどんファイルが蓄積されていって、最終的に512メガバイトを超えてしまったというのが今回の原因です。
対策としてはシンプルで、ファイルを消すようにすればいいだけでした。/tmpの配下に一時ディレクトリを作成してそこに展開し、関数が終了するときにディレクトリごと削除するように変更しました。
ということで教訓3つ目は「Lambdaは使い切りではないので、設計とか実装とかをするときは、その点を気をつけていきましょう」というような話ですね。ということでしくじり3つ目は「Lambdaが突然死した」という話でした。
では最後のしくじりに行こうかなと思います。最後は「思わぬリソースが枯渇」というしくじりです。
今回の構成図はこんな感じで、よくあるWebサイトになっています。ELBがあってEC2が冗長化されていて、EFSでEC2間のファイル共有をしている。データベースはRDSでほとんど冗長化されていますよというような、すごくよくある一般的なWebサイトの構成です。
ある日「サイトがつながらない、遅い」となりました。まず初動確認します。まず一番大事なEC2はちゃんと動いていました。じゃあ今度はEC2の中身ですね。CPU、メモリ、プロセス……。大丈夫でした。次はDBがボトルネックになっているか。コネクションとかも見たんですがDBがボトルネックになっているわけでもなさそうでした。
じゃあ何が原因なんだと思っていろいろCloud Watch Logsなどを見ていると、何かがめちゃくちゃ減っている。よく見てみるとEFSのバーストクレジットを使い切っているということがわかりました。
EFSのバーストクレジットとは何かという話なんですけれども、EFSのRead/Writeの性能というのはEFSで実際に使っている容量に依存しています。
1ギガバイトあたり50キビバイト/秒なので、1ギガバイトしか使っていなかったら50キビバイト/秒の性能しか出ないというような仕様です。この基本性能より多くの高い性能のパフォーマンスを求められる場合は、バーストクレジットというものを一時的に使ってRead/Writeの性能を引き上げるというような構造になっています。
このクレジットは貯金みたいなものを使うんですけれども、先ほど説明した1ギガバイトあたり50キビバイト/秒の基本性能より下回る期間にクレジットがどんどん回復して、逆にその基本性能を超えるパフォーマンスが必要な時はバーストクレジットを消費するというかたちです。この貯金を使い切ってしまうと基本性能しか出せなくなります。
今回サイトがダウンしたのは、基本性能、要はサイトの閲覧にそもそも耐えられなかったというのが原因になります。EFSで使っていた容量が数ギガバイトというレベルだったので、基本性能が200とか300キビバイト/秒しかなかったと。これって画像とかを読み込んだりするとすぐに超えてしまってバーストクレジット頼みになってしまいます。
結局基本性能以上のパフォーマンスをずっと求められ続けていたということで、クレジットがリリース直後からどんどん消費されていって、かつクレジットを回復する余地もなくじわじわとクレジットを消費し続けていって最終的にクレジットがなくなってパフォーマンスが出せなくなったということが原因でした。
今回EFSを使っていたんですが、こんな少ない容量だとは思わなかった、そもそも監視ができていなかったというのもあり、そこら辺はちょっと反省点かなと思っています。
対策としては、プロビジョンドスループットモードというものに変更しています。これはあらかじめどれぐらいのパフォーマンスが必要なのかというのをこちらで指定できるモードです。なのでこのモードではそもそもクレジットという概念がないので、クレジットが枯渇するということも気にせず使うことができます。ただ先ほどのバーストのモードよりはお金がちょっと高いよというモードになっています。
ということで教訓4つ目としては「クレジットには気をつけろ」という話ですね。とくにバーストクレジットというものを使うようなサービスについてはクレジットが枯渇していないかどうか、枯渇しそうかどうかという辺りに気をつけてもらえればなと思います。
その他バーストクレジットがあるサービスはいくつかあります。有名なのはEC2のCPU、T2とかT3系のCPUですね。ここも同じく基本性能というのが決められていて、基本性能を超えるようなCPUのパワーが必要なときはクレジットを使って一時的にCPUのパフォーマンスを90パーとか100パーとかが出せる、基本性能以下のCPUのときにクレジットが回復する。クレジットを使い切ってしまうと基本性能しか出ないのでCPUのパワーが出せなくなって大変なことになるので、本番のところで使うときは気をつけましょうというのはよく言われている話かなと思います。
EBSについても同じです。今回EFSでしくじりが発生したんですけれども、EBSでも同じようにバーストクレジットがあるので、こちらもバーストクレジットを使い切ってしまうとEC2とかRDSとかからのアクセスがすごく遅くなってサービスに影響が出てしまう可能性があります。特にRDSもEBSを使っているという点には注意が必要かなと思っています。RDSで容量を少なめに設定して作る場合に、こんな注意書きが出てくるんですね。
「100キビバイト未満の汎用ストレージを、高スループットワークロード用にプロビジョニングした場合、初期の汎用IOクレジットバランスを使い切った時点で、レイテンシーが大きくなる場合があります」
ということで、今お話した内容の通り、少ない容量だと基本性能は出ないので、少ない容量なのにRead/Writeがすごく発生するような環境で使ってしまうと、バーストクレジットを使い切ってパフォーマンスが出なくなるよということですね。
ということでしくじりをまとめていきます。
しくじり1つ目は「Athenaで170万円の請求がきた」。しくじり2つ目は「EC2が復旧できない/できたのにヘン」。しくじり3つ目は「Lambdaの容量を使い切って突然死ぬ」。しくじり4つ目は「ECSのバーストクレジットを使い切ってダウンする」というようなしくじりでした。
これらについてそれぞれの教訓は、「アンチパターン、ダメ、ゼッタイ」ということで、アンチパターンは止めましょう。教訓2は「それ、ちゃんと復旧できる?」ということで、AMIから復旧テストができればしたほうがいいです。教訓3つ目は「Lambdaは使い切り、でもない」ということで、Lambdaが使いまわされることを前提として設計しましょう。教訓4は「クレジットには気をつけろ」ということで、バーストクレジットには注意が必要です。
ということで、もし少しでも気になったところがありましたら、ぜひご自身のAWS環境を確認してもらえればいいかなと思います。
最後に宣伝です。弊社cloudpackはAWSに限らずいろいろなクラウドをやっていますので、かついろいろな職種で人を募集していますので、クラウドとイチャイチャしたい人はぜひホームページなどからご応募ください。
発表としては以上になります。ご清聴ありがとうございました。
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略