Amazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS FargateAmazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS Fargate
非同期処理とリトライと冪等性 - GS2 Blog
今回の記事は普段の GS2 のアップデート告知とは少し毛色が異なり、技術的なトピックを扱うエントリーです。 gs2.hatenablog.com こちらで告知した消費アクションの分岐処理を実装するにあたって、どのようなアプローチで課題に向き合ってきたのかを解説しようと思います。 非同期処理とリトライ まずは、非同期処理とリトライについて考えてみましょう。 非同期処理とは？ 「API を呼び出すと、処理の結果が返ってくる。処理の途中でエラーが発生したらエラーが返ってくる」というのが同期処理です。 この場合、エラーハンドリングは呼び出し元に委ねられますので、比較的シンプルに処理を行うことができます。 一方で、非同期処理とはどういうものか？というと 「API を呼び出すと、処理を動かし、処理IDを応答する」「処理IDを指定して完了を通知」「処理IDを指定して処理結果を取得」 というように呼び出し
EC2のcronバッチを「EventBridgeをトリガーにStep Functionsを起動」に置き換えると、エラーハンドリングが快適になる
AWSのEC2で定期的なタスクを自動化するために、cronを使用しているケースも多いと思います。 しかし、Amazon Linux 2023ではcronがデフォルトで無効になっています。これはcron以外に、cronのようなバッチ実行・定期実行する仕組みがあるということなのかと思い、cronを使わずにE2上でバッチ実行・定期実行する仕組みを考えてみました。 そして、Amazon EventBridge、AWS Step Functions、およびAWS Systems Manager startAutomationExecutionを組み合わせて、EC2インスタンス上でバッチ・定期実行を試してみましたので、紹介します。 特に、Step Functionsを使用することで、エラーハンドリングや通知が容易になり、安全にバッチ実行できるようになります。 エラーハンドリングは以下の状態を把握したい
注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
公開日 2024/05/28更新日 2024/07/25注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女
Moving from DynamoDB to tiered storage with MySQL+S3
Originally we implemented a feature to persist an event-stream into DynamoDB to allow customers to retrieve them. This proved effective, serving as a strong use case for a key/value storage, yet the drawback was its high cost. Moving to provisioned billing-mode reduced cost by ~50%, but that was not going to be sustainable as we scaled to more customers. We also kept multiplying the cost each time
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support | Amazon Web Services
AWS News Blog Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support Today, we are announcing that your MySQL 5.7 and PostgreSQL 11 database instances running on Amazon Aurora and Amazon Relational Database Service (Amazon RDS) will be automatically enrolled into Amazon RDS Extended Support starting on February 29, 2024. This will help avoid unpl
TerraformがAWS SSO(Single Sign-On)に対応してました | DevelopersIO
上記エントリを書いた際(2020/10/29時点)には、TerraformでAWS SSO(Single Sign-On)のリソースをプロビジョニングすることはできませんでした。が、その後terraform-provider-awsのv3.23.0、v3.24.0で一部リソースのプロビジョニングができるようになりましたので、使ってみたいと思います。 Support for Managing AWS SSO Permission Sets · Issue #15108 · hashicorp/terraform-provider-aws 追加された Resource / Data Source Resource aws_ssoadmin_account_assignment aws_ssoadmin_managed_policy_attachment aws_ssoadmin_permiss
AWS SSOを図解してみた | DevelopersIO
AWS SSOのコンソール画面を触ってると、「んん？？どういうこっちゃ??♂️」みたいに混乱することありませんか？画面に沿ってなんとなく設定はできたけど、どういう仕組みになっているかわからないというか… すみません、うまく言語化できていない自覚があるんですが、以下のような点がモヤモヤしています。 ユーザー&グループ、アカウント、アクセス権限セット各概念の関係性がわからない いや、俺はそもそもアクセス権限セットがどういうものなのか理解していないのでは？(モヤモヤ?) 今回はこのモヤモヤを解消するために、SSOの概念を図解していきたいと思います。SSOコンソール上での以下各操作によってどういうリソースが作成され、それぞれがどう動作するのかまとめます。 初期状態(SSO有効化前) SSOを有効化する ユーザーやグループを作成する アクセス権限セットを作成する アカウントにユーザー・グループを割
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
AWS Systems Manager で実現する SSH レスでセキュアなクラウド運用
AWS Startup Tech Meetup Online #3 の登壇資料です。 ※映像はこちら 【p3】CodeZine の記事 https://codezine.jp/article/detail/12714 【p12】SSM セッションマネージャーのデモ https://www.youtube.com/watch?v=cc7jLW0FzzI 【p22】IAM 権限の設定例 https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-restrict-access-examples.html 【p22】AWS CLI プラグイン https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-
Chatwork Amazon EKS Case Study
Chatwork Uses Amazon EKS to Increase Operational Efficiency, Support Over 6.5 Billion Messages Chatwork has been using Amazon Web Services (AWS) to power its popular business chat tool "Chatwork" since March 2011, when the AWS Asia Pacific (Tokyo) Region first became available, and has been evolving its architecture ever since. The company moved to a container-based architecture in 2016 and was se
Migrating our PHP Legend System from EC2 to Kubernetes, Part 1 - kubell Creator's Note
Why did Chatwork migrate from EC2 to Kubernetes? Issue 1: Deployment becomes unstable when the EC2 instance exceeds about 40 machines Issue 2: A rollback cannot be performed depending on the deployment status Kubernetes as a solution Kubernetes as an option Conclusion Hello! This is cw-ozaki of the SRE Department. The task of migrating PHP’s legend system from EC2 to Kubernetes that I have been in
Migrating our PHP Legend System from EC2 to Kubernetes, Part 2: The ideas behind our migration strategy - Chatwork Creator's Note
Hello! This is cw-ozaki from the SRE department. This post will be a continuation of Part 1, and I will explain the strategy with which we migrated our system to Kubernetes. creators-note.chatwork.com Our strategy for migrating to Kubernetes 1. Add a spec to EC2. Using ServerSpec 2. Add a simple E2E to the service launched in EC2. Convert the runbook to IaC with Ansible. 4. Run the spec and E2E wi
Migrating our PHP Legend System from EC2 to Kubernetes, Part 3: Cluster Structuring in Chatwork and Update Strategies - kubell Creator's Note
Hello! I’m cw-ozaki from the SRE Group. This is a continuation of the Part 2 article. Assuming that migrating from EC2 to Kubernetes is fine, I will discuss how Chatwork’s Kubernetes clusters are structured and how the updates are strategized. creators-note.chatwork.com creators-note.chatwork.com These topics don’t come up very often. I hope this can be an opportunity to hear a little more about h
Migrating our PHP Legend System from EC2 to Kubernetes, Part 4: Application Migration Tactics Matched to Kubernetes Cluster Update Strategy - Chatwork Creator's Note
Hello! I’m cw-ozaki, and I work in the SRE department. Continuing on from part three, I’d like to consider how to migrate applications to new clusters in line with the Kubernetes cluster update strategy in this installment. creators-note.chatwork.com creators-note.chatwork.com creators-note.chatwork.com Simple summary of the last article Current framework at Chatwork 1. Route53 -> CloudFront 2. Cl
Tools supporting kubernetes cluster in Chatwork (2020 version) - Chatwork Creator's Note
Hello, this is Sakamoto from the SRE Department. I run at least one full marathon every year, but unfortunately, I couldn't make it in 2020. I managed to run under 90 minutes (89 minutes) in the half-marathon held just in February, and I was aiming to run under 3 hours and 10 minutes this year but, unfortunately, there was nothing I could do. I was not particularly interested in participating in t
What we did to stabilize DNS on Kubernetes cluster - kubell Creator's Note
This time, I would like to talk about how I fixed DNS errors on EKS (Chatwork's EKS is operated using a single multi-tenant cluster) Service becomes unstable when the number of pods exceeds a certain number Culprit of conntrack overflow was kube-dns (CoreDNS) Increasing the conntrack max value autoscale kube-dns Deploy node-local-dns too DNS-related services started to become unstable again once n
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
巨大なテーブルのテーブル定義を無停止で安全に誰でも変更できるようにする / Table-definitions-for-huge-tables-can-be-modified-by-anyone-safely-and-non-disruptively
WEBアプリケーションにおけるAWS Lambdaを用いた大規模な非同期処理の実践
