なぜAmazonLinuxを利用すべきなのか #AWSreInvent | DevelopersIO
AWSではEC2向けにAmazon Linuxという独自のディストリビューションが頒布されています。最新版はAmazonLinux2023です。Amazon Linux 2023の特徴や、以前のAmazon LinuxからAmazon Linux 2023へ移行する手法についてみていきます。 こんにちは。ゲームソリューション部の出村です。AWSre:Invent2023のセッションである「Amazon Linux 2023 and beyond」のレポートをお届けします。 概要 Industry-leading security, optimal performance on Amazon EC2 instances, and great integration with other AWS offerings are the key reasons to use Amazon Linux
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリングから継続
クラウド・ネイティブのお作法（2）「リトライ」～効率的なリトライ手法「Exponential Backoff and jitter」とは何か
こんにちは。アマゾンウェブサービス クラウドサポートエンジニアの小武です。Amazon EC2、Amazon RDS、Amazon Redshiftなどのサービスの他、AWSの内部を支える裏側の技術に日々Dive Deepしています。本連載ではAWSサポートのエンジニアがそれぞれ「今一番AWSユーザーに伝えたいこと」を連載の形でお届けしています。 私の担当回では、AWSという巨大な分散システムを支える技術要素のうち、アーキテクチャ設計、プログラミング技術のいくつかについて見ていきたいと思います。これらは、AWSの内部を支える技術というだけでなく、皆さんのアプリケーションをダウンタイムゼロのシステムに近づけるための基礎技術、クラウド・ネイティヴなアプリケーションを構築する基礎的なテクニックとも言えると思います。 その基礎的なテクニックは大きく、下記の4つがあります。 非同期処理（Asynch
AWSユーザーは必ず覚えておきたいExponential Backoffアルゴリズムとは何か - yoshidashingo
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 Exponential Backoff 直訳すると「指数関数的後退」つまり、指数関数的に処理のリトライ間隔を後退させるアルゴリズムのことです。 詳しくはWikipediaに記載があります。 Exponential backoff - Wikipedia 日本語でブログに書かれている方もいらっしゃいます。 exponential backoffのメモ – Siguniang's Blog これを見ていると、どうやらこのアルゴリズムは古くから通信装置において、イーサネットフレームのデータ送信時にコリジョン（衝突）を検出したら一定時間待機して再送して、処理を完結させるためのアルゴリズムとして使われているようです。 通信機器の世界に限らず、アプリケーションの分野でも、大規模で予測不能な処理量を有限なリソースでさばく
AWS SDKのエクスポネンシャルバックオフを確認してみた | DevelopersIO
AWSのドキュメントに登場する「エクスポネンシャルバックオフ」という見慣れない単語の詳細が気になったので、実際にAWS SDKを用いて確認してみました。 エクスポネンシャルバックオフとジッター Wikipediaの日本語翻訳記事から引用します。 https://en.wikipedia.org/wiki/Exponential_backoff さまざまなコンピュータネットワークで、バイナリ指数バックオフまたは切り捨てられたバイナリ指数バックオフは、多くの場合ネットワークの輻輳を回避するために、同じデータブロックの繰り返しの再送信の間隔を空けるために使用されるアルゴリズムを指します。 通信分野で使用される再試行（リトライ）処理のアルゴリズムのようです。 AWSでは以下のページに解説があります。 エクスポネンシャルバックオフの背後にある考え方は、連続したエラー応答の再試行間の待機時間を徐々に長
リリース手法多すぎﾜﾛﾀｧ B/G、カナリア、機能フラグ、ダークローンチ、A/Bテスト、、など - Qiita
この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり
AWSでサーバーレス設計を考える時の手引き書 - Qiita
はじめに サーバーレスに触れて数年が立ちました。 そろそろ人にある程度説明ができるレベルの知識と経験が備わったような気もするので、年末なのでまとめてみました。 サーバーレス気になっているけれども、という人に少しでもためになればいいなーと思います。 サーバーレス基礎 皆さん、サーバーレス設計という話を聞いたことはあるでしょうか？ まずサーバーレスについて説明しますが、世の中にはたくさん解説記事があるのでそちらも適宜参照ください。 サーバーレスでも実際にはサーバーは存在する サーバーレスとは開発者がサーバーのことを意識しなくてもよい、ということ Function as a serviceに代表されるように、あるプログラムの実行環境を提供するが、プログラムの動作環境は開発者は意識する必要はない、というイメージ 恐らく、AWS Lambdaが一番理解しやすいと思います。 AWS Lambdaではプ
SaaS系スタートアップのリアルなAWSアーキテクチャ設計
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第一回〜べき等性 (冪等性/idempotency) ってなんだ!? - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
そもそも、べき等性とは、どういうことを言うのでしょうか ? これは「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念です。 例えば、注文処理を考えます。画面インターフェースで、注文確定 / 送信ボタンを押すという操作で二度三度押してしまうユーザーがいます。これで同じ内容の注文が複数回登録されてしまったら問題です。こういったケースでは、画面側で連続して押せないような実装を追加したり (①)、サーバー側で同じ注文の処理であることを認識して適切に一つの処理と判断するようなこと (②) が必要です。 この例では、画面側の制御を入れたほうが簡単なように見えます。しかし、現実には画面とサーバーとの間のネットワークの問題や画面以外からの HTTP コールなどを考えると、このような重複リクエストが起こってしまうという可能性はゼロではありません。 このようなものへの対処として、サーバ
［速報］AWS、クラウド障害をわざと起こす「AWS Fault Injection Simulator」発表。カオスエンジニアリングをマネージドサービスで実現。AWS re:Invent 2020
Amazon Web Services（AWS）は、開催中のオンラインイベント「AWS re:Invent 2020」で、アプリケーションに対してクラウド障害のシミュレーションを行える新サービス「AWS Fault Injection Simulator」を発表しました。 クラウド上で稼働するアプリケーションの耐障害性などを高めるために実際にクラウド障害をわざと発生させて問題点をあぶりだす手法は、「Chaos Enginieering（カオスエンジニアリング）」と呼ばれています。 Netflixが2012年にカオスエンジニアリングのためのツール「Chaos Monkey」を公開したことで広く知られるようになりました。 参考：サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 今回発表された「AWS Faul
「アマゾンを断固ITベンダーとして認めない」と言い切るSIerは何者なのか
「日本にはIT産業が無い。IT利用産業があるだけだ」。もう5年以上も前の話だが、ある経営者の「暴論」を聞いて感銘を受けたことがある。日本にはITベンダーと呼ばれる企業が多数あるにもかかわらず、なぜこの人は「IT産業が無い」と言うのか。その理屈はなかなか刺激的だった。 具体的にはこうだ。ITの領域で新たなテクノロジーを生み出すことで世界に新たな価値を提供するのがIT産業である。大手をはじめ日本のITベンダーのほとんどは新たなテクノロジーを何も生み出していないのだから、日本にはIT産業と呼び得るものは存在しない――。 当時の私はこの論点に全く気付いていなかったので、本当に感心した。だが話を聞いていて、ふと次のように思った。ひょっとしたら日本にはIT産業だけでなく、まともなIT利用産業も存在しないのではないか。その疑問から発想して、この「極言暴論」で記事を書いた。冒頭の経営者の論がシャープだった
クラウドは雲の中にあるんじゃない サーバールームで動いているんだ - orangeitems’s diary
AWS障害と物理層の関係 昨日のAWS障害、冷却装置の故障によりサーバーが高温となり自動停止したことが原因であったと報じられていますね。 japan.zdnet.com Amazon Web Services（AWS）の東京リージョンで8月23日に発生したElastic Compute Cloud（EC2）サービスの障害は、冷却システムの故障により高温化した一部のサーバーがシャットダウンされたことが原因だったという。同日午後9時までにEC2の大部分のサービスが復旧したとしている。 AWSによると、障害は東京リージョンの一部で使用している複数の冷却システムが故障したことで発生した。これによってEC2サービスのサーバー機器の温度が上昇し、サーバーがシャットダウンされたことで一部のインスタンスやEBSボリュームに影響が生じたとしている。 冷却装置。クラウドを利用しているユーザーは最も聞きたくない
「AWSとGCPを“選択可能”にしておく」LIFULLに学ぶ長生きするインフラ構築術 - エンジニアHub｜Webエンジニアのキャリアを考える！
「AWSとGCPを“選択可能”にしておく」LIFULLに学ぶ長生きするインフラ構築術 多くの開発に導入されるクラウドサービスですが、LIFULL社では、AWSとGCP、両サービスを同時に使用しているそう。同社のインフラの変遷と、併用の背景を聞きました。 AWSとGCP、「どちら」を「どうやって」使うか サーバの肥大化を阻止するべく、オンプレからAWSへ移行 マイクロサービス化し、「影響範囲」を狭めることで得られたメリット 「使い分ける」のではなく、「両方を使える」ことが継続性を生み出す インフラ構築における技術的な選択肢はさまざまですが、なんらかのクラウドサービスを活用するということは多くのエンジニアが検討する手段でしょう。 昨今ではクラウドサービスは多くの企業から提供されており、エンジニアにとって多様な選択肢が提供される一方、どのサービスを選ぶべきかという悩みもあるでしょう。筆者の周りで
AWS インスタンスの種別とサイズを選択する
これはアーカイブされたコンテンツですパブリック クラウドへの展開は引き続きサポートされますが、サードパーティーのパブリック クラウドへの展開に関するコンテンツは更新されなくなります。 Tableau Server の展開の最新コンテンツについては、「Tableau Server 導入ガイド(新しいウィンドウでリンクが開く)」および Tableau Server ヘルプの「」「展開(新しいウィンドウでリンクが開く)」セクションを参照してください。 アクセスが可能な場合は、Tableau Cloud を使用することをお勧めします。詳細については、以下を参照してください。 Tableau Cloud 手動移行ガイド管理者向けの Tableau Cloud トライアル版(新しいウィンドウでリンクが開く)Tableau Cloud: 管理者向けのスタート(新しいウィンドウでリンクが開く)概要ワークロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Solutions Architect ブログ: Exponential Backoff And Jitter
「義務教育で教えて欲しい」AWSの『技術的なお問い合わせに関するガイドライン』は職業を問わず全人類が読むべき