Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 2024年7月29日、日本時間20時ごろからAWS Cloud9の新規利用に制限がかかるようになりました。 新規作成したAWSアカウントや、これまでCloud9を利用していなかったAWSアカウントで、Cloud9コンソールにアクセスできなくなっている模様 AWS Organizations配下に作成した新規AWSアカウントも同様の状況 当初、本件に関するAWSからの公式アナウンスはなく、数日前から「Cloud9から類似環境への移行方法」を紹介する意味深なブログが投稿されていたのみでした。 そして7/31にようやく、AWSのチーフエ
おはこんばんちは、DBREの橋本です。 今回は、Amazon RDS Proxy（以降RDS Proxyとよぶ）を用いたRDS for MySQLインスタンスおよびAurora MySQLクラスタのオンラインスイッチオーバーの手法について、ある程度社内での運用が確立してきましたので解説いたします。 従来のアップデート手法 AWS上でRDS for MySQLインスタンスやAurora MySQLクラスタ（以降これらをデータベースとしてまとめてよぶ）を運用している場合、それらのエンジンバージョンの更新を行ったり、OSバージョンの更新に伴う再起動を実施する必要があります。これらの更新を行う場合、以下のような方法が考えられます。 対象のデータベースに直接更新を適用する スナップショットを作成し、更新済みのデータベースとして復元する 更新済みの空のデータベースを新規作成し、そちらにデータを移行し、
AWS、引退を迎えたサーバラックのサーバやスイッチを分解修理し、データセンターで再利用していることを明らかに。ハードウェアの製品寿命をできるだけ延ばすのが目的 Amazon Web Services（AWS）は世界中に大規模なデータセンターを展開しており、そこでは何十万台ものサーバやネットワークスイッチなどが稼働しています。 同社はそこで一定の時期を迎えて引退したラックに搭載された多数のサーバやスイッチを分解修理し、テストし、再びデータセンターで利用していることを明らかにしました。 これにより既存のハードウェアの製品寿命をできるだけ延ばすことを目的としていると説明しています。 説明によると、引退時期を迎えたサーバラックはまずデータを安全に消去したうえで、世界中の主要なリージョンに設置されている「リバースロジスティクスハブ」に送られます。リバースロジスティクスハブは、IT資産処分センターと、
真野 智之 (Tomoyuki Mano) <tomoyukimano@gmail.com> version 1.0, 2020-06-19
本記事は 初夏のAWSアワードエンジニア祭り 1日目の記事です。 🍦 告知記事 ▶▶ 本記事 ▶▶ 2日目 💻 尾澤です。 この度、2023 Japan AWS All Certifications Engineers に選ばれました。 更新が不安です。 というわけで今回はAWSアワードとかはあまり関係ないですが、 私が日頃業務で対峙するECSさんについてお話ししようかと思います。 ECSとは もう今となってはコンテナといえばこれというサービスですね。(?) 改めての説明ですが、 Amazon ECS（Elastic Container Service）は、AWSが提供するコンテナオーケストレーションサービスです。 Webサービスなどを構成する場合、コンテナ単体で動かすにはさまざまな運用課題があるため、 基本的にはオーケストレーションツール（ex: Kubernetes, e）を使いま
AWS LambdaでRuby 3.2の利用が可能に、初のRuby 3.xサポート。Ruby 2.7のサポートは2023年12月で終了 Amazon Web Services（AWS）は、同社のサーバレス基板「AWS Lambda」でRuby 3.2ランタイムのサポートを開始したと発表しました。 これまでサポートされていたのはRuby 2.7でしたので、AWS Lambdaとしては初めてのRuby 3.xのサポートとなります。 Rubyは2.xから3.xへのバージョンアップにおいて実行速度の向上を大きな目標としていました。特に今回サポートされたRuby 3.2では、Ruby 3.1でメインラインにマージされ、安定して稼働する実用段階に到達したJITコンパイラ「YJIT」が搭載されています。 YJITは、ECサイト構築サービスで知られるShopifyが開発を進めてきたもので、大規模なRail
【TimeTree × みてね勉強会】 グローバル対応への挑戦 〜SRE/インフラ編〜 https://mixi.connpass.com/event/285041/
Amazon Web Services (以下AWS)の利用開始時にやるべき設定作業を解説します。AWSの利用開始とは、AWSアカウントの開設を意味しますが、より安全に利用するため、AWSアカウント開設直後にやるべき設定がいくつかあります。この連載ではその設定内容を説明します。 AWS Organizationsを使用することで、複数のアカウントに自動的にこういった初期設定を行うことも可能ですが、この連載では新規で1アカウントを作成した場合を前提とします。複数アカウントの場合も、基本的な考え方は同じになります。 設定作業は全１９個あり、作業内容の難しさや必要性に応じて以下３つに分類しています。 少なくともMUSTの作業については実施するようにしましょう。 MUST ：アカウント開設後に必ず実施すべき作業 SHOULD ：設定内容の検討または利用方法を決定のうえ、可能な限り実施すべき作業 B
概要 先日、非公式ながらGitHub ActionsのAWSアクションで以下のような面白い機能が発表されました。 よりわかりやすく嚙み砕くとこういうことです。 Circle CIやGitHub ActionsでAWSを使う場合は事前に環境変数にアクセスキーとシークレットキーを登録させてCIを動かしてきましたが、そのためにIAMユーザーを発行して鍵を管理するのは手間だったのでこれはいいアップデートです。 今回はTerraformとGitHub Actionsを組み合わせたCI/CDにこの機能を取り入れてGitHub ActionsにIAMロールを渡してEC2インスタンス構築のCI/CDを実装してみようと思います。 GitHub Actionsを用いたTerraformのCI/CD TerraformでAWSリソースをデプロイする際にGitHub ActionsやCircle CIでCI/CD
各領域の最前線で活躍されるエンジニアや研究者を招き、インフラ技術を基礎から応用、普遍的な技術から最新技術まで網羅的に学ぶ、インフラ勉強会シリーズ「Infra Study Meetup #1 - #10」。2ndシーズンの第3回として、クラスメソッド株式会社の鈴木氏が登壇。AWS EC2でのIPv6通信について紹介します。 自己紹介鈴木亮氏（以下、鈴木）：よろしくお願いします。クラウドであればIPv6簡単に使えるよ、ということで話したいと思います。自己紹介ですが、クラスメソッドというAWSの構築支援などをしている会社に所属しています。 AWSの構築をお手伝いしながら、ブログなども書いています。 趣味で自転車乗っていて、毎年7月あたりは北海道に行ったりしていました。2022年あたりには、また行けるようになったらいいなと思っている今日この頃です。 AWSでIPv6がいつから使えるようになったかち
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
インスタンス 利用するインスタンスタイプを選択してください。 データ転送量 EC2からインターネットへ送信されるデータ量をGB単位で入力してください。Webサイトを例にすると、ページあたりの容量が2MBで、月間10万PVの場合、下記のようになります。 2 * 100000 / 1024 ≒ 195GB ライセンス費用が発生するOS OSはAmazon Linuxを前提にしているので、RHELやWindows ServerなどのOSを利用する場合は、価格が高くなります。 リザーブドインスタンスなど オンデマンドインスタンスを前提にしているので、あらかじめ予約することで安く利用できるリザーブドインスタンスや、余っているインスタンスを安く利用できるかもしれないスポットインスタンスなどを利用する場合は、もっと安くなります。 選択肢にないインスタンスタイプ インスタンスタイプは、よく使いそうなものに
こんにちは、IT基盤部の川原﨑です。 私の所属する第四グループでは、超大規模ゲームタイトルおよびゲームプラットフォームのインフラを運用しております。 そこでのAuroraの高速フェイルオーバーの仕組みと、実際に無停止で切り替えを行った手順について紹介させていただきます。 はじめに 第四グループでは、コストコントロールの一環でInstance数の増減・Instance Typeの変更を頻繁に実施しています。 例えば、 イベントなどでリクエスト増加が見込まれるときにInstance数を増やす、またはInstance Typeを1つ上のものに変更する リクエストが減少傾向にあれば、Instance数を減らす、またはInstance Typeを1つ下のものに変更する などです。 これはWebサーバだけにとどまらず、DBサーバについても同様です。 EC2上でMySQLを運用している環境では、フェイル
お久しぶりです、エムスリーエンジニアリンググループ 兼 QLife エンジニアの園田です。 今回は、Rails のアプリを AWS の Lambda で動かして、ALB 経由でアクセスしてみようという内容です。 実現するためには ALB から Lambda を呼び出す。 Lambda で Rails を動かす。 上の２つをクリアするだけでいいので、動かすだけならとても簡単にできてしまいます。 １つめは、ALB の TargetGroup に Lambda 関数が指定できるので、それを使います。 ２つめは、Github にある aws-samples/serverless-sinatra-sampleの Lambda 関数ブリッジ用ソース (MITライセンス、以降 aws-samples のサンプルソース と表記します) を利用にすればほぼ何もいじることなく実現できます。 serverles
掲題のエラーに当たってサポートに対応教えてもらったのでメモ。 事象 原因 パーティションの例 テーブルのスキーマ パーティション毎のスキーマ 対応 参考 事象 CSVをGlueを使ってパーティション分割して、AthenaでプレビューしてみたらHIVE_PARTITION_SCHEMA_MISMATCHというエラーが発生しました。 SELECT * FROM "tablename" limit 10; Your query has the following error(s): HIVE_PARTITION_SCHEMA_MISMATCH: There is a mismatch between the table and partition schemas. The types are incompatible and cannot be coerced. The column 'drop
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon ECS デプロイツール ecspresso 開発5年の歩み
