Terraformerとしてコードを書いて思うこと | フューチャー技術ブログ
こんにちは。TIGの伊藤です。この記事は秋のブログ週間2021の3日目です。 はじめに私は普段会社でクラウドをまたいでTerraformを日々書いたり、メンバーに教えたりしています。もはや俗に言うプログラミング言語を書かずにここまで全振りしてきたくらいなので、比較的自信を持ってコードを書いて仕事をしています。 特にここ最近はほぼ1からコード設計をして運用まで持っていくこともあり、「より腐りにくい、より息の長いコード」というものを考えるようになりました。Terraformだからこその「定期メンテを簡易にするためには」「より簡単に変更するためには」をひたすら突き詰めていった結果、アツい気持ちが生まれ、今回は筆を取っています。 そんな私のアツい気持ちをしたためた今回の記事ですが、可能な限り例も添えつつ、いくつか解説できればと思います。公式にも実は載っているような内容もあったりしますが、日本語の記
ECSを運用で使っていて難しいと思った点 - アジャイルSEの憂鬱
ECSを触っていて今まで難しいと思ったことを雑にまとめておく。 ECSを仕事で運用するときに必要な知識が多すぎる。こんなの社内に1人AWSマスターいないと無理だ...— 神速 (@sinsoku_listy) 2021年8月10日 タスクロールとタスク実行ロールの違い ECSを長く触っているのに、いつも混乱する。 タスクロール コンテナ内の権限 S3やSESなどの権限をつける タスク実行ロール コンテナ外の権限 ECRやParameter Storeの権限をつける ECSのデプロイ時に静的ファイルが404になる ECSを触った初期に遭遇した。 詳細は以下のQiitaの記事が分かりやすい。 参照: ECSのデプロイ時に一定確率で静的ファイルが404になる問題を回避する 回避する方法はいくつかある。 静的ファイルをS3に置く CodeDeployの OneAtATime を使う CodeDep
あと2時間でElastiCacheのメモリが枯渇！そのときあなたは何をしますか？
突然ですが... あなたは、あるゲームプロジェクトの本番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか？ はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクトの本番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし
運用担当者のためのAWS改善マップ | DevelopersIO
Trusted Advisor AWS Trusted Advisorは、コスト、パフォーマンス、セキュリティ、耐障害性、サービスの制限について、アドバイスしてくれるサービスです。 サポートプランによって、チェック項目が異なります。 セキュリティについては、セキュリティグループの無制限アクセス、S3バケット許可などをチェックしてくれます。 セキュリティについては、赤の指摘項目は0にしましょう。 insightwatch insightwatchは、弊社が提供するサービスです。 AWSアカウントが、ガイドラインに沿ったセキュリティのベストプラクティスで運用されているかチェックします。 複数アカウントをチェックしやすいため、たくさんのアカウントを運用されているかたに特にお勧めします。 どなたでも無料でご利用いただけます。 IAMの見直し、定義 IAM のベストプラクティスに基づいた見直しを行い
AWS特有の運用イベントまとめ（非障害系） | DevelopersIO
【ACM】 サーバー証明書の有効期限切れ／自動更新失敗 ACMは、CloudFrontとELBと連携してサーバー証明書を提供するサービスです。 ACMで発行する証明書は1年毎に更新する必要がありますが、基本的には自動更新されます。 ただし、場合によっては自動更新が失敗するケースがあります。 検証の仕組みは、以下のドキュメントを確認してください。 自動ドメイン検証の仕組み 自動検証に失敗した場合、EメールおよびPersonal Health Dashboardで通知されます。 自動検証に失敗した場合 また、外部で発行された証明書を利用している場合は、手動で更新する必要があります。 再インポートの手順は、以下のドキュメントを参照してください。 証明書の再インポート EV証明書が必要なケースでも無ければ、ACMで証明書を取得してオペレーションが発生しないようにしておきたいですね。 【Route
Terraform管理の取捨選択は運用で状態が変わるかどうかで決めると良い - tehepero note(・ω<)
2016 - 06 - 07 Terraform管理の取捨選択は運用で状態が変わるかどうかで決めると良い 今のプロジェクトではTerraformを使って AWS 上のインフラを構築しているのですが、1年程運用して向いてるケース、そうではないケース等が明確になってきました。 今一度Terraformとは Terraform とは Hashicorp 社のプロダクトで、インフラを管理・構築・破棄をコードベースで行うことができ、まさにInfrastructure as Codeを地で行くような OSS プロダクトです。 AWS だけではなく、その他多くのIaaS/PaaS/ SaaS といったサービスの構成をコードで構築することが可能になります。最近はDockerの管理もサポートしていたり、 GitHub のチームや リポジトリ までもが管理できたりします。 全てが運用に即したものではない Te
【社内資料公開】AWSトラブルシューティングページまとめ／より早い原因把握のために心がけること | DevelopersIO
はじめに こんにちは植木和樹です。オンプレで10年近くサーバーの保守運用をやっていた経験からいいますと、AWSの障害発生率は非常に低くて驚きます。数百台規模のサーバーを扱ってますと、毎日どこかでのサーバーでディスク、CPUファン、メモリーパリティエラーなんかの故障が起きていて日々対応に駆けまわってた覚えがあります。 さてAWSの障害発生率が低いといってもゼロというわけではありません。仮に0.1%だとしても1000日つまり3年運用していれば1回くらい障害に遭遇するものです。0.01%だったとしてもサーバーが1万台あれば1日1回なにかしらのトラブルに遭遇しても不思議ではありません。 トラブルに遭遇すると、当然サービスや処理に影響をきたしてしまうわけで早期の暫定処置と、その後に恒久的な対策が求められます。その時に重要なのは早く正しく原因を特定することです。トラブルシューティング力が重要です。 A
AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録
AWS は Management Console や API ですべて操作できます（Direct Connect など一部例外もあります）。データセンターの物理的なセキュリティなどは AWS が責任を負うところで、ユーザーはまったく意識する必要はありません。 その代わり、OS やミドルウェアの管理、アプリケーションの設計や実装、適切な権限管理などはユーザーが責任を負うところです。 今回はあまり取り上げられないけど、すごく大事な権限管理についてまとめてみました。自分が仕事で関わっているプロダクトで権限管理を見直すときに調べたことをベースにしていますが、もっと良いプラクティスがあればぜひ教えてください。 AWS アカウントは使わない 普段の運用で AWS アカウントは使いません。 AWS アカウントとは、最初にサインアップするときに作られるアカウントです。 このアカウントは Linux で言う
社内Gyazoの画像をAmazon S3に逃がしてスケーラブルに運用する - 酒日記 はてな支店
Gyazo、便利ですよね。大変便利なので、社内でプライベートなGyazoサーバを用意して使っている会社も多いと思います。 うちでもサーバのパフォーマンスは特に必要ないので社内に適当なVMを立てて運用していたのですが、数年単位で運用していると画像ファイルが増えていくためdiskをなんとかする必要に迫られました。 ここでどんどん増えるファイルはAmazon S3に逃がそう、という自然な発想に至るわけですが、Gyazoサーバアプリが投稿を受けたときにS3にアップロードするような改修をするのは年末の忙しい時期に面倒。楽したい。 ということで S3 と nginx を組み合わせていいかんじに運用できるようにしてみました。 Gyazoに限らず、 ローカルに書き込んだファイルをhttpで閲覧する 一度書き込まれたファイルには変更がない ファイルは消えないでどんどん増える ようなものには応用できると思いま
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
2013年版! SonicGardenにおけるherokuでのサービス運用構成 | mah365
ちょうど去年の今頃、SonicGardenにおけるherokuでのサービス運用構成をご紹介しました。去年の比較して、今ではherokuで本番運用されているサービスも増えているかと思いますが、実際の構成例はあまり紹介されていないようです。去年ご紹介した内容も少し古くなっていますので、2013年バージョンとして、再度ご紹介したいと思います! 去年からの変更点 去年と比較して大きく変わっている点は、以下の3点ですねー。 バックアップ取得方法の見直し & 監視の導入 Route53愛してる! ログ取得のアドオンをPapertrailに変更 バックアップ取得方法の見直し & 監視の導入 @interuが去年のJAWS-UG in Nagoyaで講演したように、「本当にバックアップ取れてるの？」というのは重要な視点ですね! なので、バックアップを取得するところと、監視するところ、セットで構成するように
開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
「AWSを活用して少人数で複数のサービスを運用するコツ」〜JAWS-UG in Nagoya〜 - よかろうもん！
10月6日に名古屋で開催された第4回JAWS-UGにて、「AWSを活用して少人数で複数のサービスを運用するコツ」というテーマで、SonicGardenの運用に関しての考え方や取り組みについてお話させていただきました。 当日の資料を以下から見えるようにしておきます。 「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜 また、資料のインプットとなっている記事については以下にリンクを用意しておきますので、時間があるときに読んでいただけましたら幸いです。 AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) - よかろうもん！ データやログのバックアップを楽に実現するために活用すべきライブラリ〜Backup〜 - よかろうもん！ 実践で使えるEBSスナップショット取得スクリプト - よかろうもん！ トータルフットボールなチームの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Auto Scalingを一年間運用してみた