EKSのバージョンライフサイクルに組織として対応する - Chatwork Creator's Note
先日行われた Chatwork Dev Day 2021 で、SRE部からは Immutable Clusterに対する定期Version Upgrade戦略 ということで、EKSのアップグレードへの対応について話しました。 www.youtube.com speakerdeck.com ChatworkではSREだけでなく開発チームも含めて、EKSを導入した1.17以降、1.20までスキップすることなくアップグレードを実施しています。 今回は、技術的な話ではなく、組織としてどのようにEKSのアップグレードに対応していったかを説明したいと思います。 ChatworkのEKS運用 1. EKSのバージョンライフサイクルの確認 2. アップグレード方針 バージョンごとに必ずアップグレードする必要があるのか？ スキップできる数は？ 3. アプリケーションの確認 4. スケジュール確認 切り替え完
Migrating our PHP Legend System from EC2 to Kubernetes, Part 1 - Chatwork 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 - Chatwork 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 - Chatwork 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
１年後のChatworkインフラの話 (2020年版) - Chatwork Creator's Note
こんにちわ。id:cw-tomitaです。 この記事は、Chatwork Advent Calendar 2020 - Qiita の21日目の記事です。 Advent Calendarシーズンももうすぐ終わりですが、入社して初めての年のAdvent Calendarでこんな記事を書いたな〜と、ふと思い出し、 creators-note.chatwork.com この記事を書いてから３年という、何となくキリのいい数字を迎えたので、これまでの歩みを振り返りつつ、来年やろうとしていることの紹介しつつ、あわよくば、そういうのめっちゃ興味ある！って人にChatworkのことを知ってもらうきっかけとなることを期待して、当時の記事タイトル*1をオマージュ*2して、この記事を書いていきたいと思います。 tl;dr 2017年末からの変化 2021年に向けて やってきアイテム達 EKSの定期version
pt-online-schema-changeを用いたスキーマ変更 on Amazon Aurora MySQL - Chatwork Creator's Note
こんにちわ。id:cw-tomitaです。 この記事は、Chatwork Advent Calendar 2020 - Qiita の3日目の記事です。 早速ですが、皆さんはauto incrementなRDBのtableのidにはどのような型を利用されていますか？ Chatworkでは多くのテーブルでint型が指定されているのですが、９年前にサービスを開始した時には想像もつかないくらいに多くのお客様に使っていただけるサービスへと成長した結果、int型なauto incrementのidを利用しているテーブルで、レコード数がintの上限を迎えそうなテーブルが複数現れ、どかっとまとめてALTER TABLEを実施するという2020年を代表する一大イベント(?)がありました。 今回は、その時に利用したpt-online-schema-changeというツールを使ってのALTER TABLEの実
Biryani プロジェクト(メッセージ検索機能のCloudSearchからElasticsearchへのリプレイス)について vol.4 - 差分マイグレーション編 - - Chatwork Creator's Note
こんにちは、梶原(cw-kajiwara)です。 Biryani PJシリーズでの投稿です。今回の記事ではメッセージ検索機能におけるメッセージの差分マイグレーションを行うKafka Consumerアプリケーション、通称Indexerについて紹介いたします。 vol.1ではプロジェクト発足の背景・概要を、vol.2ではPJ前後のシステム構成、Elasticsearchの負荷試験考察やCWでの運用方法、vol.3ではデータマイグレーションについて紹介していますのでご興味あればぜひこちらもご覧ください。(ご興味あれば、と言いつつも読んでもらっていることを前提にしてしまっているところは所々あります) Biryani プロジェクト(メッセージ検索機能のCloudsearchからElastcsearchへのリプレイス)について vol.1 - Chatwork Creator's Note Biry
Biryani プロジェクト(メッセージ検索機能のCloudSearchからElasticsearchへのリプレイス)について vol.3 - データマイグレーション編 - - Chatwork Creator's Note
こんにちは、安達(cw-adachi)です。 前回までの記事では、vol.1でBiryani(ビリヤニ)プロジェクトが発足した背景や概要を、vol.2ではシステム構成、負荷試験や運用周りを紹介してきました。今回はこれまでサラッとしか触れてこなかったHBaseからElasticsearchへのデータマイグレーションについて紹介します。大量(2020年7月時点で60億以上)のメッセージデータを確実に、なおかつ出来るだけ速くマイグレーションするための戦略や細かな工夫をお伝えできればと思います。 Biryani プロジェクト(メッセージ検索機能のCloudsearchからElastcsearchへのリプレイス)について vol.1 - Chatwork Creator's Note Biryani プロジェクト(メッセージ検索機能のCloudSearchからElasticsearchへのリプレイス
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の実装等に関しては今回は取り上
Biryani プロジェクト(メッセージ検索機能のCloudSearchからElasticsearchへのリプレイス)について vol.1 - Chatwork Creator's Note
こんにちわ、SRE部のcw-tomitaです。 今回は、7/17(金)に行われた全社合宿で、プロジェクトとしては惜しくもベストPJ賞を逃したものの、オーディエンス賞を受賞(全社跨いで、半期の間に実施された数々のPJの中で厳選された３つのPJだけが賞をもらえる)し、また、このプロジェクトをリードしたcw-kajiwaraが、このプロジェクトを通しての圧倒的なコスト削減の実績からCFO賞を個人受賞するという、上期の社内の賞レースを席巻した、メッセージ検索機能のリプレイス(通称：Biryani PJ) *1 に関して紹介したいと思います。 写真は、先週行われた全社のオンライン(役員・準備/進行担当の方を除く）合宿での、感動の受賞シーン。 目次 目次 tl;dr 移行前の構成 移行を検討することになった背景 規模の変化 構成の変化 移行先の検討の開始 Elasticsearchの事前調査 Powe
Kubernetesをめぐる冒険、の後日譚 - Chatwork Creator's Note
Chatwork 坂本です。 本ブログは2020年1月23日に行われた、下記のコンテナ支部での発表を補足する内容で、eksctlの設定ファイルとvariantの具体的な使い方に焦点を当てて書きたいと思います。 jawsug-container.connpass.com speakerdeck.com 目次 eksctlの設定ファイル preBootstrapCommandsについて variantの具体的な使い方 まとめ 最後に(どうでもいいニュース) eksctlの設定ファイル 発表資料では、主にeksctlをvariantでwrapして、運用している、という話をしましたが(さらにeksctlの設定ファイルのテンプレートからの生成もvariantで)、そもそもなんでそのような運用が必要なのか、というのを、eksctlの設定ファイルの構成から説明していきたいと思います。 下記がChatwo
３週間で出来たEvent SourcingでCQRSなアーキテクチャ上でのHBaseのupgrade - Chatwork Creator's Note
プロジェクトのリーダーである、cw-sakamotoがこの超重要プロジェクトを終え、軽い燃え尽き症候群になっているので、代わりにcw-tomitaが代筆しております。 マラソンガチ勢(ベストタイム３時間１７分)であるcw-sakamotoによって、Carbon X(50マイルでの世界記録を出したランナーが履いていたランニングシューズの名前)と名付けられた、このHBase upgradeプロジェクト、 dogsorcaravan.com その名に恥じない、プロジェクト開始から終了まで３週間という短納期で完遂することができました。今回はこのプロジェクトに関して書きました。 tl;dr Event SourcingでCQRSなシステムの上で動いてるHBaseのversion upをblue-green形式で実施した。 計画から実行まで３週間程度で完了するというスピード感で、大きな事故もなく凄く上
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
JWT形式を採用したChatWorkのアクセストークンについて - ChatWork Creator's Note
JWTを使うことは難しい？ こんにちは、かとじゅん(@j5ik2o)です。最近、JWTに関する以下のブログが話題です*1。 どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org このブログで言及されているのは、JWTをセッションの保存先に選ぶことで「何が問題なの？」に書かれているリスクがあるよ、という話*2。確かにいくつか検討することがありますね。 auth0.hatenablog.com auth0の中の人？よくわからないけど、反論的なブログエントリが公開されています。この記事では、指摘の問題が起こらないように設計するのはあたり前では？という意見みたいです。まぁごもっともではないでしょうか。 私も技術そのものというより、要件に合わせて技術を組み合わせる設計の問題だと思っています。加えて、JWTを利用することはそんなに難しいことかという疑問があった
Prometheus形式で公開されたmetricsを、Datadog Prometheus Checkを利用して取得する - Chatwork Creator's Note
SRE部のcw-sakamotoです。 nginx-ingress on AWS で gRPC をロードバランスさせる検証 - ChatWork Creator's Noteにおいて、少しだけ言及しました、Datadog Prometheus Checkに関する内容です。 Kubernetesの監視と言えば、Prometheusのイメージが強い？ですが、ChatWorkでは、もともと非Kubernetes環境においてDatadogで監視していることから、KubernetesもDatadogで監視しています。 そこで、本記事では、DatadogによるKubernetes監視自体に関して軽く触れてから、実際の設定ファイルを示しながら、Datadog Prometheus Checkの設定や、確認方法について記載します。 Datadog Prometheus Checkとは、Prometheus
nginx-ingress on AWS で gRPC をロードバランスさせる検証 - Chatwork Creator's Note
SRE部のcw-sakamotoです。 この記事では、nginx-ingressをk8s on AWSで動かして、さらにbackendにはgRPC serverを立てて、ロードバランスできるかどうかの検証を行いたいと思います。 アジェンダ 背景 環境 gRPC serverの起動 gRPCの各リソースの作成 grpcurlを利用して確認 nginx-ingress-controllerのインストールとingressの作成 nginx-ingress-controllerのインストール ingressの作成 ELBの準備 clientからの確認 まとめ 背景 gRPCのアプリをkubernetesで動かす要件があり、検証が必要になった kubernetesでgRPCをよしなにロードバランスさせるのにnginx-ingressが妥当そうであり、各機能を確認しておきたかった https://ww
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部メンバーが２人発表しますので、この記事では、その内容を一足先に紹介したいと思います。「チャット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
