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
Biryani プロジェクト(メッセージ検索機能のCloudSearchからElasticsearchへのリプレイス)について vol.2 - Chatwork Creator's Note
こんにちわ、cw-tomitaです。 前回の記事に続いて、Biryaniプロジェクトに関して、あれこれと書いていきたいと思います。なお、この記事は、先日公開した以下の記事の続きとなりますので、こちらを未読の方は、是非vol.1からお読みいただければと！ creators-note.chatwork.com 先の記事では、PJが始まった経緯、Elasticsearchを第一候補として選んだ理由等について書きました。今回は、POC/実装を進めていく中で、苦戦したポイントと解決方法に関して、主だったポイントを挙げていきたいと思います。 最初にどのようなものを作ったかをざっと紹介し、その上で、 今回の記事の中では、Elasticsearch 自体にフォーカスをあてて、色々と紹介していきたいと思います。 Sparkでのデータマイグレーションや、Scalaのindexerの実装等に関しては今回は取り上
AWS DevDay Challengeに参加してきました(チーム関東) - Chatwork Creator's Note
こんにちわ。SRE部のcw-tomita です。 昨日のチーム吹田の記事に続いて、チーム関東として、先週行われたAWS DevDay Challengeという、1 day Hackathonイベントのことを書きたいと思います。 tl;dr Q毎に実施している部署合宿の機会を使って、DevDay Challengeというイベントに参加してきました。 普段の業務ではあまり触らないAWSのServerlessのservice周りの知識が増えるとともに、自分たちのサービスの機能のdog foodingも出来て、めちゃくちゃ学びが多かった。 参加までの経緯 cw-ozaki からの問いかけに挙手をした所から全てが始まりました。 ちなみに 🙋♂️ の絵文字を翻訳すると、「serverless周りは色々と情報のキャッチアップはしてるつもりだけど、ハッカソン的なイベントは久しく出てないし、今年からMG
AWS Summit スタートアップ特設エリアで、kubernetesとサーバレスについてプレゼンテーションします - Chatwork Creator's Note
こんにちわ。SRE部の cw-tomita です。 さて、今日から待ちに待ったAWS Summit Tokyoが始まっていて、皆さん楽しんでいることと思います！ AWS Summit Tokyo 2018（2018年5月30日～6月1日）｜AWS ChatWorkのSRE部は現在５名で、東京オフィスに３名、大阪オフィスに１名、フルリモートが１名で、全員がリアルな場所に集まることは中々無いのですが、このAWS Summitはその中の１つの機会となっていて、そういう意味でも(主に懇親会で行くバルバッコアのシュラスコが)とても楽しみにしていました🍖 我々SRE部、ただ肉を食べるだけではなく、明日、5/31(木)にAWS Summit スタートアップ特設エリアでプレゼンテーションの枠をいただき、SRE部メンバーが２人発表しますので、この記事では、その内容を一足先に紹介したいと思います。「チャット
１年後のチャットワークのインフラの話 - Chatwork Creator's Note
こんにちは。インフラマネジメント部の id:cw-tomita です。 今年のAWSのre:Invent凄かったですね！！たくさんの驚きの発表があって、最近の技術イベントの中では際立って刺激的な内容だったと思いました。 興奮冷めやらぬ中、今回、発表された機能たちを反映させていくと、１年後のチャットワークのインフラはどのようなものになるのか？？少し想像してみたので、今日はその内容を共有したいと思います。 注：ここに書かれる想像は、個人のモノであり、所属する組織の正式なロードマップとは一切関係ありません。 現状 昨年末の巨大リリース(Falcon)による変化 チャットワークは昨年の末にFalconプロジェクトという大きなリリースを行いました。チャットサービスの根幹であるメッセージデータ部分の処理をごっそり作り変える大プロジェクトでした。この構成変更に関する詳細は、以下のスライドにまとまっていま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
