MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開［PR］
MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開［PR］ Kubernetesのようなコンテナ環境では、MySQLデータベースのようなステートフルで高い安定性が求められるソフトウェアを運用することは難しいと、以前は考えられていました。 しかし現在ではステートフルセットのような機能もKubernetesは搭載し、実装も安定してきていることから、ステートフルなアプリケーションをKubernetesで実行できる状況が十分に揃ってきました。 それだけではありません。Kubernetesには運用自動化を支える「Operator」と呼ばれる拡張機能が登場しました。これを用いると、Kubernetes上でさまざまなアプリケーションでの運用作業の多くが人手を介することなく自動的に行えるようになります。 そしてこのOpera
次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering
※こちらは先日実施された DeNA インフラエンジニア / SRE MEETUP で話した内容を Blog 記事化したものです！ こんにちは！IT基盤部の熊谷です。IT基盤部にて大規模ゲームのインフラを見ている 新卒２年目のインフラエンジニアです。この記事では “DeNA でのデータベース運用とそのツラミ” と、“TiDB導入への検証・検討” をご紹介させていただきます。 データベースの最適解 DeNA のデータベース構成は最適解を求めて改良を積み重ねてきました。最初期の構成、(便宜上、第１世代と呼びます) では VM Instance 上に MySQL を構築し管理する MySQL on EC2 構成。続く第２世代では、マネージドサービスを駆使した Aurora MySQL 構成。この２世代の中で生じた “ツラミ” を解消する次の世代、言わば 第３世代に該当する新しいデータベース構成を現
![次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/a7a9ef2e383cbfc8885ee9e5572b0b143267e771/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F01%2Finfra-meetup-tidb%2Fcover.png)
MonotaROのデータ基盤10年史（前編） - MonotaRO Tech Blog
おしらせ：12/23 に後編記事がでました！ tech-blog.monotaro.com こんにちは、データ基盤グループの香川です。 現在モノタロウではBigQueryに社内のデータを集約し、データ基盤を構築しています。 およそ全従業員の6割が日々データ基盤を利用しており、利用方法や目的は多岐に渡ります。 データ基盤グループはこれまでデータ基盤システムの開発保守と利用者のサポートを主な業務として取り組んできましたが、これら多岐にわたる社内のデータ利用における課題の解決及びさらなるデータ活用の高度化を目的として、今年の5月よりデータ管理を専門に行う組織として新たに体制を再構築しました。 そこで改めて組織として取り組むべき課題や方向性を決めるために、まず自分たちの現在地を知ることが重要と考え、データ基盤の歴史を振り返り、社内のデータ活用における課題やそれを取り巻く状況がどう変わってきたのかを
MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズの Kubernetes 基盤を開発している Neco プロジェクトの ymmt です。 サイボウズ製品のほとんどはデータベースとして MySQL を採用しています。 現在 400 を越える MySQL のインスタンスを運用しており、これら全てを新しい Kubernetes 基盤に移行していく予定です。 Kubernetes 上でアプリケーションやミドルウェアの運用を自動化するソフトウェアのことをオペレーターと言います。 大量の MySQL インスタンスを Kubernetes 基盤に移行するにはオペレーターが必須であると考え、技術顧問の @yoku0825 さんの監修の下で MOCO というソフトウェアを開発しオープンソースライセンスで公開しました。 本記事では Kubernetes 上の MySQL オペレーターの状況と、開発した MOCO の機能を詳細に解説いたします。 M
GitLab.comはどうやって6TBのPostgreSQLを9.6から11にたった2時間で移行したのか? | DevelopersIO
GitレポジトリのホスティングサービスGitLab.comは2020年の5月に 6TB あるPostgreSQL 9.6クラスターをたった2時間のメンテウィンドウ中に11.7へアップグレードしました。 GitLab.comのエンジニアブログに、このPostgreSQLのメジャーアップグレードプロジェクトが解説されていたので、かんたんにご紹介します。 How we upgraded PostgreSQL at GitLab.com | GitLab ポイント PostgreSQL 9.6から 11.7 へのメジャーアップグレード 2時間のメンテナンスウィンドウ内でアップグレード完了 データサイズは6TB DBクラスターは GCP 上の 12台の VM インスタンスで構成 クラスターはアップグレード用の8台とリカバリー用の4台に分割 pg_upgrade & ハードリンクでインプレースアップグ
運用中のPostgreSQLのスキーマを無停止で安全に変更する | 株式会社ヌーラボ(Nulab inc.)
初めに こんにちは。ビジネスチャットサービスTypetalkを開発・運用している吉田です。Typetalkではデータの永続化ストレージとしてPostgreSQLを利用しています。扱うデータ量は多く、チャットというサービスの性質上書込み頻度はとても高いです。PostgreSQLを使い日々開発を進めていると、追加する機能によってはスキーマを変更する必要があります。メンテナンスを計画・告知してサービスを止めてしまえば、時間はかかるかもしれませんがスキーマの変更はそう難しくありません。しかしTypetalkはユーザーが日々の業務を進めるために利用しており、サービスが止まるとコミュニケーションが取れなくなります。業務を円滑に進めるためのビジネスチャットツールですので、極力サービスは止めたくありません（最後の計画メンテナンスは2019年6月30日で1年以上前となっています。）。本記事では以下の3つのケ
マルチクラウド構成におけるMySQL Group Replicationの利用事例紹介
こんにちは、滝澤です。 前回の記事『WireGuardによるマルチクラウド構成VPNの事例紹介』に引き続き、社内事例を紹介します。 弊社ハートビーツではMSP（Managed Service Provider）サービスの可用性向上のために、社内基盤をマルチクラウド構成で運用しています。 複数のクラウド拠点のネットワーク間をWireGuardというVPNトンネルのソフトウェアで接続しています。 さらに、リレーショナルデータベース管理システムにはMySQLを利用しており、MySQLのレプリケーション機能の一つであるGroup Replicationを使って拠点内および拠点間における冗長化を行っています。 今回はこのMySQL Group Replicationの利用事例を紹介します。 行っていることをまとめると次のようになります。 マルチクラウド構成（Azure, AWS, GCP）において、
「ハイトラフィック運用 〜スループットの向上を目指して〜」という話をしました #devio2020 | DevelopersIO
こんにちは(U・ω・U) AWS事業部の深澤です。 さて弊社では昨日よりDevelopersIO2020 〜connect〜というイベントが開かれています。 セッションもりもりだよ！ あつまれー！https://t.co/viwYQqiKG7#devio2020_connect — 深澤俊 (@shun_quartet) June 3, 2020 その中で僕は「ハイトラフィック運用 〜スループットの向上を目指して〜」という話でセッションさせていただいたので本ブログではその発表した内容を資料と共にご紹介します！ 動画 資料 セッション内容 今回扱うこと、扱わないこと 今回は観点をメインに紹介します。 それぞれのエンジン等による細かい違いやチューニング方法には触れません。 例：MySQLとPostgras等 メトリクスはCloudWatchのものをご紹介します。 今回はあくまで概要と基本です。
「orchestratorとGTID運用を支える監視」の勉強 / Monitoring orchestrator and GTID operation
MySQL Casual Talks vol.13
Hadoop環境のクラウド移行 | BLOG - DeNA Engineering
IT基盤部の nodoka です。 私の業務はWebサービスの運用が中心でしたが、数年前からHadoopを中心とした分散基盤環境のインフラも見るようになりました。 当初は巨大なHadoop環境の管理を体系化して引き継ぐことと、運用における属人性を排除することが喫緊の課題でした。 それが落ち着くと、ご多分に漏れずクラウド化を検討・推進するようになったので、その流れをまとめてみようと思います。 DeNAのHadoop環境と改善策 Hadoopが抱える課題 GCPへの移行 embulk利用におけるTips DeNAのHadoop環境と改善策 DeNAにおけるHadoop環境の歴史は古く、DeNAのほとんどのサービスが利用しています。 各サービスでは分析したいログやDBのスナップショットをHadoopのファイルシステムであるHDFSに一旦置きます。 そのHDFSに置かれたファイル群をHadoopを
「MariaDB Platform X3」登場、OLTPとOLAP機能をひとつに統合。フルマネージドサービス「MariaDB Platform Managed Service」も開始
「MariaDB Platform X3」登場、OLTPとOLAP機能をひとつに統合。フルマネージドサービス「MariaDB Platform Managed Service」も開始 MariaDBは、同社がオープンソースで開発するデータベースの最新バージョン「MariaDB Platform X3」と、フルマネージドサービス「MariaDB Platform Managed Service」を発表しました。 Announcing #MariaDB Platform X3 – now available in the #cloud as a managed service. https://t.co/YACCP8j4a3 — MariaDB Corporation (@mariadb) 2019年1月16日 MariaDBは2010年にMySQLのフォークとして登場し、その後、主要な製品ラ
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
MySQLサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか - Y-Ken Studio
MySQLサーバで希に遭遇するディスク残量障害事例と共に紹介します。 こちらは、以下エントリよりネタをパクりましたインスパイアしました。すみません。 Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか - 元RX-7乗りの適当な日々 Linuxサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか - tagomorisのメモ置き場 今回紹介する対処パターン 今回は4つの方法を紹介します。 不要なデータベース/テーブルを削除 スロークエリログ/クエリログを削除 バイナリログを削除 どれのパターンにも属さないレアなシチュエーション 不要なデータベース/テーブルを削除 あまりそういうケースは無いとは思いますが、 DROP DATABASE foo;やDROP TABLE foo;で削除します。 スロークエリログ/クエリログを削除 du -sc
1台から500台までのMySQL運用 MySQL Beginners
5. On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Our Service (livedoor) Amazon MechanicalAmazon Mechanical Turk Mechanical Turk Amazon Mechanical Turk Mechanical Turk Turk Amazon Amazon t/ Workers Workers Requester Requester On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Amazon MechanicalAmazon
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソーシャルゲームDBの�危機回避