1. 目的 ElastiCache for Redis のサービス更新通知が来た。AWS社(公式)の説明によると、サービス更新実施時の影響は数秒程度の断とのこと。本当にそうなのか？と心配なため、検証環境にて実際の接続断時間(ダウンタイム)を確認する。 2. 予習 AWS社(公式)による説明はこちら。接続断時間に関する記載部分を引用。 お客様または Amazon ElastiCache により 1 つ以上の Redis クラスターにサービス更新が適用されると、選択したすべてのクラスターが更新されるまで、一度に 1 つのノードの更新をそれぞれのシャード内で適用します。ノードの更新には数秒のダウンタイムが発生しますが、それ以外の Redis クラスターは引き続きトラフィックを処理します。 以前のアップデートの際に、既に実機確認している記事が何個かあり、AWSの言う通り、数秒程度の接続断の様子。
こんにちは。Feature2 Unitのうなすけです。我々のチームの担当範囲のひとつには「データの入出力」というものがあり、お客様からAPI呼び出しやファイルアップロードなどで受け取ったデータを適切に処理するコンポーネントの運用・開発をしています。 AWS Lambdaの処理が失敗するようになった 皆さん、AWS Lambdaはお使いでしょうか。我々も様々な処理にAWS Lambdaを活用しています。一例として、ユーザーからアップロードされたCSVファイルのバリデーションを行うLambda functionをAWS Step Functionsの一部として実行しています。 ある日、機能追加として日本語を含む1CSVファイルのアップロードを許可したのですが、CSVファイルのバリデーション処理でエラーが発生するようになりました。日本語も受け入れるようにしたタイミングと同時にRuby runti
推奨アラーム - Amazon CloudWatch
以下のセクションでは、ベストプラクティスアラームを設定することをお勧めするメトリクスを一覧表示しています。各メトリクスには、ディメンション、アラームの目的、推奨しきい値、しきい値の根拠、期間の長さとデータポイントの数も表示されます。 一部のメトリクスはリストに 2 回表示されることがあります。これは、そのメトリクスのディメンションの組み合わせによって異なるアラームが推奨される場合に発生します。 アラームを発生させるデータポイント数は、アラームが ALARM 状態になるのに必要な違反データポイントの数です。評価期間数 は、アラームの評価時に考慮される期間の数です。この 2 つの数が同じ場合、期間の値がその数だけ連続してしきい値を超えた場合にのみ、アラームは ALARM 状態になります。アラームを発生させるデータポイント数が評価期間数より少ない場合、そのアラームは「N 件中 M 件」のアラーム
ECSメインにAWSサービスを利用してコンテナの運用設計を考えてみます。 コンテナの運用設計 ECS 上で稼働するWebアプリケーションを前提に運用の要件を考えてみます。 コンテナを使用したマイクロサービスの運用は、モノシリックなシステム運用とは少し異なります、以下の項目を運用項目としてピックアップします。 可用性/スケーリング CI/CD ロギング トレース モニタリング ECS/ECR のアーキテクチャ まずはECS/ECR のアーキテクチャについて触れます。 Amazon ECSはコンテナの作成、実行、停止といった管理をメインとしたサービスであり、Amazon ECRは Dockerのレジストリサービスとなります。リポジトリにあるイメージをプッシュしたり、イメージの保管等を行います。 全体的なイメージを以下のように理解をしています。 ECSの機能 まずECSです。 ECSは複数のエン
AWSマネジメントコンソールへのサインインを、IAMユーザー（ユーザー名とパスワード）認証でしていて疲弊していませんか？ 毎回 私は疲れています。 私が担当する案件では、特別な理由がない限りIAM Identity Centerを経由してサインインすることにしています。 IAM Identity Centerを推奨している理由 理由①：IAMユーザーの資格情報が漏洩するリスクを最小限に抑えるため 情報漏洩リスクを排除するためには、注意喚起や社内ルールを設けるだけでは十分なセキュリティ対策とはなりません。IAMユーザー認証を使用しないか、又は別の認証手段に切り替える必要があります。IAM Identity Centerでは、内部でAWS Security Token Service（STS）が発行されるため、セッション時間による一時的な認証を実現できます。 理由②：複数アカウント間のサインイ
はじめに アクセスキー発行するのって非推奨なの？ 普段、CLI操作はCloudShellや、Cloud9上で行うようにしているのですが（環境構築 したくない。）、デスクトップ上で操作したい時があります。 そこで、一番簡単な方法であるアクセスキーを発行しようとすると、こんな代替案を提案されます。 この警告にモヤモヤしていたので、今回は「IAM Identity Center」を使ってみた。っていう記事です。 実は、アクセスキーは丸見えだったり。 最近、職場の本番リリース中に気づいたのですが、AWS CLIに保存したアクセスキーや、シークレットアクセスキーは丸見えだったりします。 (↓は既に削除しているキーたちです。) アクセスキーの何がいけないのか？ おおむね以下の理由から、非推奨の模様。 永続的な認証情報だから。 キーが流出すると、攻撃者がリソースにアクセスし放題。 キーの管理が面倒。 複
モノタロウのプラットフォームエンジニアリング部門 コンテナ基盤グループの宋 明起です。 私たちは、アプリケーション開発者からコンテナシステムの認知負荷を取り除き、アプリ開発に専念できるコンテナ基盤の構築と基盤を改善し、開発者はより楽に、より安全にアプリケーションのデプロイと運用できるように支援しています。 背景 基本設計 方針 構成 サンプル モニタリング サンプル 障害 障害1. Memory overflowエラーが発生 障害2. 大量のログが欠損になっている (refresh_interval) 障害3. まだ一部ログが欠損になっている (Prestop) [FAQ] 背景 モノタロウでは以下の記事にあるようにバックエンドのAPIをコンテナ化から始め様々なレイヤーの様々なアプリケーションをEKSの上で運用しています。 EKSコンテナ移行のトラブル事例：ALBの設定とPodのライフサイ
こんにちは、新規プロダクトの開発をしています、a2 （@A2hiro_tim ）です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開
AWSがMySQLのODBCドライバを開発、オープンソースで公開。純正ドライバ互換、Amazon Auroraでの高速なフェイルオーバー、AWSのシークレットやIAMのサポートなど
AWSがMySQLのODBCドライバを開発、オープンソースで公開。純正ドライバ互換、Amazon Auroraでの高速なフェイルオーバー、AWSのシークレットやIAMのサポートなど AWS ODBC Driver for MySQLは、MySQLコミュニティが配布している純正のMySQL用ODBCドライバと置き換えて使える互換性を備えつつ、AWSでMySQLを利用する際により優れた機能と性能を実現できるように実装されています。 具体的には、Amazon Auroraにおけるフェイルオーバー時の再接続の高速化です。AWS ODBC Driver for MySQLはクラスタのトポロジーと各 データベースインスタンスがプライマリなのかレプリカなのかの役割のキャッシュを保持することで、接続先のデータベースインスタンスに障害が発生し、別のデータベースインスタンスへのフェイルオーバーが発生したときに
Photo via Visual hunt ヌーラボアカウントではつい先日、Amazon RDS for MySQL から Amazon Aurora へと移行しました。ここでは、その経緯と実際に実施した作業を簡単にご紹介させていただきます。 移行の経緯 ヌーラボアカウントは Backlog や Cacoo、Typetalk といったヌーラボのサービスへの認証機能を提供しています。もし認証機能が使えないとすべてのサービスを利用できなくなってしまいます。そのため、ヌーラボアカウントには常に認証機能を提供し続けられるような、高いアベイラビリティが求められています。 ヌーラボアカウントではこれまで RDS for MySQL を利用していましたので、MySQL 互換を掲げる Amazon Aurora は、リリースされたときから移行の可能性を検討をしてきました。Aurora のメリットについては
こんにちは、サーバーサイドエンジニア1年目のharukiです。 先日、AWS上でS3トリガーのLambda起動を試していたところ、なかなか上手く行かずに少しハマってしまったため、 今回はそちらの原因と対処法＆プチ調査結果についてまとめたいと思います。 本題の前に 問題発生の状況 実際に発生しているイベントを確認してみる 前回成功していたファイル 前回失敗していたファイル 解決方法 もう少し詳細に 確かめてみる 16777215 byteのファイルアップロード時の3Sイベント 16777216 byteのファイルアップロード時の3Sイベント さいごに 本題の前に まず、今回のお話に出てくるシステムのイメージ図はざっくりと下記の様な形で、 LaravelからのS3へのファイルアップロードに対してLambdaを起動するといった仕組みになっています。 なお、この際AWSの3Sイベント通知ではObj
最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介します いわさです。 SaaS on AWS では大きく 4 つのフェーズ（設計・構築・ローンチ・最適化）で役立てる事ができるコンテンツが提供されています。 設計フェーズでは技術面からコンプライアンスに準拠したりセキュリティベースラインを考える必要があります。 これらについてベストプラクティスが提案されている動画コンテンツがあります。 その中で初期段階で実施出来ることとして次のステップが紹介されていました。 セキュリティ周りは Well-Architected Framework や Security Hub の適用から始めることも多いと思いますが、様々な制約からすぐの導入が難しい場合もあります。 そんな方に本日は上記の中の AWS Startup Secur
Amazon Linux 2023でパッケージを最新バージョンに更新したい時、少し注意が必要です。 Amazon Linux 2と同じように「yum update」を実行してもパッケージは更新されません。 パッケージ更新をしてみる まずは素直にパッケージを更新してみます。 ちなみに、Amazon Linux 2023からベースOSがRHEL/CentOSからFedoraに変わったため、デフォルトのパッケージ管理ツールも「yum」から「dnf」へと変更されました。 ということで、「sudo dnf update」を実行してパッケージを更新してみます。 # パッケージの更新 $ sudo dnf update Last metadata expiration check: 17:12:26 ago on Sun Oct 8 16:31:53 2023. ====================
はじめまして、SRE チームの村山です。 今回、弊社の主要サービスで使用している Aurora MySQL のアップグレードを行いましたので、対応内容や得られた知見についてご紹介したいと思います。 背景 弊社で使用している Aurora は、2022 年 10 月に Aurora MySQL v1 (MySQL 5.6 互換) から Aurora MySQL v2 (MySQL 5.7 互換) へとアップグレードしております。その際の対応については、以下の記事をご覧ください。 tech.synchro-food.co.jp その後も v2 を使用していましたが、2024 年 10 月 31 日 をもって v2 の標準サポートが終了になるため、Aurora MySQL v3 (MySQL 8.0 互換) へのアップグレードが必要になりました。 docs.aws.amazon.com 変更点の
もう既に期間内ですが、2024 年 6 月 1 日以降は順次旧インスタンスクラスのインスタンスが自動アップグレードされます。 t2 インスタンスタイプは t3 へ、m4 は m5 へ、r4 は r5 へへ自動アップグレードされる予定です。 できるだけ早く新しい世代の DB インスタンスクラスにアップグレードすることが推奨されています。 私がいくつかの AWS アカウントで確認したところ、その全てではまだ旧世代インスタンスクラスの RDS for MySQL が引き続き実行出来ている状態でした。 自動アップグレードの前に AWS より事前通知（60日程度前）されるようではありますが、ダウンタイムが発生する可能性があるので、計画的に手動アップグレードするのが良いですね。 インスタンスタイプ変更手順は次のドキュメントを参考にしてください。 新規インスタンス作成は出来ない また、以前メールで案内さ
概要 最近の音声認識技術の進歩はすごいですね！ 特にOpenAIの最新モデルであるWhisper large-v3は、日本語の音声データでもかなりの高精度で文字起こしを行うことができ、APIも公開されています。 ただし簡単に使用でき汎用性も高い一方で、大量に使用する場合の高コストやプライバシーの懸念もあるため、ローカル環境で効率よく高精度な文字起こしを実現するモデルが多数開発されています。 今回は、その中でもGPUを使用した高速推論が可能な「Faster Whisper」を用いて、AWS SageMakerでカスタム文字起こしエンドポイントを構築してみたので、手順を解説していきたいと思います。 実装コードは以下のリポジトリにあります。 順番通りJupyterNotebookを実行すると問題なく動作するはずです。 Faster Whisperとは Faster WhisperはOpenAIの
使う機能 ALBのリスナールール機能です。ALBは配下のターゲットリソースにリクエストをルーティングする際に、いろいろな分岐条件を書くことができます。 2020/07/07時点で利用できる条件は以下です。 ホストヘッダ パス HTTPヘッダ HTTPリクエストメソッド 文字列のクエリ 送信元IP ルーティング先としては以下が選択できます。 ターゲットグループ さらに、重み付けにより複数ターゲットグループに一定割合毎にリクエストを振り分けることもできます。 [激アツアップデート]ALBだけでカナリアリリース(重み付け)ができるようになりました！ リダイレクト 固定レスポンス レスポンスコード、Content-Type、レスポンス本文を指定できます。簡単なエラーページならここで実装してしまうのもアリかと思います。 この条件とルーティング先を組み合わせることで、○○という条件が真のときはXXにル
Amazon S3が不正なリクエストでも利用料が加算される現象、AWSが修正を完了したと報告
Amazon S3の空のバケットに対してアクセスされると、たとえそれが第三者からの不正アクセスでエラーが返ったとしてもリクエスト料金が発生してしまうという現象について、AWSが修正を完了したと5月13日付けで明らかにしました。 これまでは空のバケットへのアクセス方法を知っている第三者が大量のリクエストを発行した場合、例えその結果「AccessDenied」（HTTP 403 Forbidden） エラーが返ったとしても、バケットの所有者には大量のリクエスト処理による利用料金が請求されてしまうという問題が発生していました。また、実質的にこれを防ぐ方法はないとされていました（AWSのドキュメント）。 4月30日にあるAWSユーザーのブログによってこの現象が明らかになった後、AWSのエンジニアは直ちに修正作業に入ったことが同社のチーフエバンジェリストであるJeff Barr氏によって示されました
はじめに 前提 ある日のこと ググってみる botocore、boto3 のバージョンを確認してみる 徐々に核心に なぜバージョン競合が発生するのか 原因まとめ 対応 おわりに はじめに サーバーワークスの宮本です。今回は本番運用していた AWS Lambda 関数が何も変更していないのに突然動かなくなった話を共有します。一見すると信じられない話ですが、最後までお読みいただけると幸いです。 前提 対象の Lambda 関数に関する基本情報（今回の話に関係ある部分のみ）は以下の通りです。 2023/01 に初回デプロイし、運用を続けていた ランタイムは Python3.9 依存ライブラリは Lambda Layer にまとめている 月に数回動かすようなバッチ処理 ある日のこと 4月某日のことです。当該 Lambda の実行でエラーが発生したことが通知されました。以下はエラー内容の抜粋です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
