並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 18 件 / 18件

新着順 人気順

マイグレーションの検索結果1 - 18 件 / 18件

  • 10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由|ハイクラス転職・求人情報サイト AMBI(アンビ)

    10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 10年以上運用されているサービスには、さまざまな技術的な負債が発生しています。今後の継続的な改善のため、いったん新規開発を止めて4年かけて全面的なリニューアルを実施した「はてなブックマーク」の開発者に、プロジェクトの課題や解決する手法などを聞きました。 改善1つに数カ月かかるなら全てを書き換えられないか 2000年代にトレンドだった開発手法の負債 過去の開発意図を探る考古学的手法 データセンター移行も見据えて刷新しよう ドメインモデル設計とScalaとマイクロサービス化 コアロジックにはScalaを採用 きちんとしたドメインモデルによる設計と実装を継続したい 段階的なリリースとデータの移行という2つの大きな課題 求められる機能に沿ったデータベーススキーマに再構築 新旧の2システムを維持しながら

      10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由|ハイクラス転職・求人情報サイト AMBI(アンビ)
    • 100億レコード超のDBを“障害ゼロ”でマイグレーション 新卒1年目が考えた2つのアプローチと3つの工夫

      インターネットやAIを駆使しながら、領域に捉われずにさらなる挑戦を行うDeNAの取り組みを紹介する「DeNA TechCon 2023」。ここで成田氏が登壇。PocochaのDBをマイグレーションしたことについて話します。 新卒1年目が100億レコード超のDBマイグレーションをした話 成田篤基氏:発表を始めます。みなさんはじめまして。成田と申します。私は2021年にディー・エヌ・エーに新卒で入社して、現在入社から2年が経とうとしています。 私は新卒1年目で、大規模なデータベースマイグレーションを行う貴重な経験ができました。本日はそのマイグレーションプロジェクトについて、体験から得た学びをみなさんにお伝えします。題して「新卒1年目が100億レコード超のDBマイグレーションをした話」です。どうぞよろしくお願いいたします。 目次です。本日はこちらの目次に沿って発表を進めていきます。 まずは私たち

        100億レコード超のDBを“障害ゼロ”でマイグレーション 新卒1年目が考えた2つのアプローチと3つの工夫
      • MySQLからPostgreSQLに移行する際のTips - そーだいなるらくがき帳

        このエントリーは Classi developers Advent Calendar 2022の18日目。 ネタはなんでもいいよ!とのことなので、Claasiに全く関係なく、MysqlからPostgreSQLに移行する際の注意点を書く。 なお、まだRDSにPostgreSQLがなかった頃のような昔の記事だがこちらに無いことを書いていく。 soudai1025.blogspot.com soudai1025.blogspot.com MySQL から PostgreSQLにデータ移行する際の注意点 MySQLとPostgreSQLは互換性がもちろんありませんので、細かいところで違いが発生します。 よく踏むデータ移行の注意点は以下の通り。 timestampやdatetimeを移行する先はtimestamp型になるが、timestamp型はタイムゾーン付きと無しがある timestamp wi

          MySQLからPostgreSQLに移行する際のTips - そーだいなるらくがき帳
        • Cloud FirestoreからPostgreSQLへ移行したお話 - ZOZO TECH BLOG

          はじめに こんにちは。ブランドソリューション開発本部FAANSバックエンドブロックの田村です。普段はサーバサイドエンジニアとしてFAANSのバックエンドシステムの開発をしています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗のショップスタッフの販売サポートツールです。FAANSでは、データベースとしてGCPのサーバレスでドキュメント指向のNoSQLデータベースであるCloud Firestoreを当初採用していました。Cloud Firestoreはサーバレスなので運用負荷が掛からず、また安価でスケーラビリティにも優れたハイパフォーマンスなデータベースです。 しかし、Cloud Firestoreを使用して開発・運用していく中で直面した様々な課題からGCPのフルマネージドのリレーショナルデータベースであるCloud SQLのPostgreSQLにデータベースのリプ

            Cloud FirestoreからPostgreSQLへ移行したお話 - ZOZO TECH BLOG
          • 魔窟と化した全文検索サーバーとふっかつのじゅもん - Cybozu Inside Out | サイボウズエンジニアのブログ

            サイボウズのクラウド黎明期から運用し続けていたSolrサーバーを Elasticsearchに置き換えるプロジェクトが先日完了しました。 プロジェクト完了報告もかねてプロジェクトのあらましを公開したいと思います。 はじめに このプロジェクトの主軸は『魔窟と化したレガシー技術をどう捌くか?』になります。 このプロジェクトの報告をする前に、いくつかエクスキューズをさせていただきます。 クラウド黎明期を支えてくれたSolrには畏敬の念に近い感謝をもっています レガシーな技術に対してマウントやディスリスペクトの意図はありません 魔窟にかかわることになってしまった人に対して負の感情は一切ありません 今回の採用している構成はElasticsearchのあるべきアーキテクチャではありません 今後、Neco 環境への移行を通して継続的に改善していきます サイボウズでのSolrの使い方と用語説明 サイボウズ

              魔窟と化した全文検索サーバーとふっかつのじゅもん - Cybozu Inside Out | サイボウズエンジニアのブログ
            • RDS Blue/Green Deployments を使ってシュッと utf8mb4 にマイグレーションした話 - カミナシ エンジニアブログ

              こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL 2(MySQL 5.7 互換)を使っています(以下 Aurora MySQL と略します)。 ある日、社内の Slack で「𠮷」などの文字列が登録できないのではないかという話が出ました。これを聞いて「あー」と思った方も多いでしょう。 MySQL で有名な UTF-8 の 4 バイト文字問題で、歴史的な理由から MySQL 5.7 以前では utf8 の文字セットは utf8mb4 ではなく utf8mb3 を指しています。 dev.mysql.com カミナシのアプリケーションは 4 バイトの文字列が入力された場合はシステムエラーを返す実装になっていますが、エラーの内容をユーザーにわかりやすく伝えることは難しいためユーザー体験としても良くない

                RDS Blue/Green Deployments を使ってシュッと utf8mb4 にマイグレーションした話 - カミナシ エンジニアブログ
              • 大規模データベースを安全にマイグレーションする仕組み - Cybozu Inside Out | サイボウズエンジニアのブログ

                こんにちは、Yakumo兼コネクト支援チームの@ueokandeです。 サイボウズには体験入部という制度があり、数週間〜数ヶ月の期間、他チームの業務を体験できます。 自分もこの制度を使い、1ヶ月ほどGaroon開発チームを体験してきました。 自分はこの期間で、Garoonの大規模なデータベースを安全にマイグレーションするための仕組みの設計と、そのプロトタイプを実装しました。 背景 Garoonはサービスのアップデートと同時に、データベースのマイグレーションを実行します。 ここでいうマイグレーションは、主に2つの処理があります。 テーブルスキーマの更新。ALTER TABLEによるカラムの追加、削除など。 データの変換。既存レコードのデータ編集など。 Garoonはメンテナンスウィンドウを設けてバージョンアップを実施します。 このバージョンアップが毎回確実に成功すればいいのですが、実際はそれ

                  大規模データベースを安全にマイグレーションする仕組み - Cybozu Inside Out | サイボウズエンジニアのブログ
                • Swiftはじめました - ゼクシィiOSアプリの場合 | Recruit Tech Blog

                  はじめに Swift はじめました。と聞くと、読者の方は「いまさら?遅すぎじゃない?」とか、「大切なのは何の言語で書くかよりも設計じゃないの?」などと思われるかもしれません。気持ちはわかります。 しかし実際、ゼクシィアプリのコードベースは今まで Objective-C 100% でした。そして、つい最近、はじめてプロダクションコードとして Swift のコードをリリースすることができました。本稿では、そこに至るまでに考えたことや、具体的なやり方を紹介できればと思います。 申し遅れましたが、この記事はゼクシィ iOS アプリの開発を担当している @tondol がお送りします。好きな結婚式ソングは lily white で「ふたりハピネス」です。1)ラブライブ!のキャラクターソングです。わざわざ脚注までお読みいただき、ありがとうございます。 背景 前述の通り、ゼクシィアプリはこれまで Obj

                    Swiftはじめました - ゼクシィiOSアプリの場合 | Recruit Tech Blog
                  • .NET Framework 3.0 で作られたアプリケーションを .NET 5 に最新化して GitHub で公開するまでに行ったこと - しばやん雑記

                    CodePlex に置いてあった .NET Framework 3.0 時代に書かれたアプリケーションを、GitHub に移行しつつ .NET 5 で動くように 2 週間ぐらい頑張った話を書きます。正直なところ 12 年前に書かれたコードを何とかするのはめっちゃ大変でした。 今回コードの改善を頑張ったので色々な実験場としても使えるようにしています。特に GitHub 周りは新しい機能を使ってみるようにしています。 .NET Framework 3.0 時代に書かれたコードを何とかするのが本当に大変だった(まだ何とか出来てない https://t.co/u5SrISQRCL— Tatsuro Shibamura (@shibayan) 2021年5月9日 実際には .NET 5 で動くようにはなっていますが、中身は古臭い実装がたくさん残っているので、ツイートの通り全然何とかなっていない状況で

                      .NET Framework 3.0 で作られたアプリケーションを .NET 5 に最新化して GitHub で公開するまでに行ったこと - しばやん雑記
                    • スキーマのバージョン管理と互換性の話 | フューチャー技術ブログ

                      はじめにはじめまして、TIGの原木です。サービス間通信とIDL(インタフェース記述言語)連載の4本目です。 気が付けば、バージョンの話0ばかりしています。 この記事ではスキーマのバージョン管理と互換性について話します。 “スキーマ”が指し示す言葉と課題一般的にスキーマのバージョン管理という話が出た場合、次のどちらかを想像する人が多いのではないでしょうか。 データベースのスキーマ(DB内のデータ構造)の変更をどうやってバージョン管理していくか サービス間通信で使用するデータフォーマット(ex. gRPCのprotobuf)をどうやってバージョン管理していくか データ構造が変わったことによりソフトウェアの改修が発生するとわかった瞬間、この問題に直面して「どうしよう…」と悩まれた経験を持つ方は数知れずいらっしゃるかなと思います。 両者において、スキーマのバージョン管理が課題だと意識するタイミング

                        スキーマのバージョン管理と互換性の話 | フューチャー技術ブログ
                      • Automating MySQL schema migrations with GitHub Actions and more

                        EngineeringOpen SourceAutomating MySQL schema migrations with GitHub Actions and moreIn this deep dive, we cover how our daily schema migrations amounted to a significant toil on the database infrastructure team, and how we searched for a solution to automate the manual parts of the process. In the past year, GitHub engineers shipped GitHub Packages, Actions, Sponsors, Mobile, security advisories

                          Automating MySQL schema migrations with GitHub Actions and more
                        • Ruby on RailsでDB マイグレーションする際にシステム障害を回避するための工夫 - LCL Engineers' Blog

                          Webエンジニアの森脇です。 LCLでは、DB設計変更で、DBマイグレーションをする際にシステム障害を回避するためのいくつか工夫をしています。今回は、その内容を簡単にご紹介いたします。 migration作成時の注意 ブランチ戦略 原則、migrationのブランチは独立させるようにしています。 migrationとコードのデプロイはタイミングを分けたほうが安全であり、さらに他のコード修正と混ぜると、切り戻し等がやりづらいくなるため 新規JOBなど既存コードに影響しない場合は、独立させなくても可 既存コードに影響を与えない migration実行後も既存コードで正常稼働するように、migrationを作成します。 以下にケース別の手順を紹介します。 テーブルの新規作成 テーブルの新規作成は特に意識することはありません。 ただし、既存テーブルへ外部キーを貼る場合は、後述の手順に従い注意が必要

                            Ruby on RailsでDB マイグレーションする際にシステム障害を回避するための工夫 - LCL Engineers' Blog
                          • 第138回 オンラインスキーママイグレーションツール gh-ostを使ってみよう[その1] | gihyo.jp

                            今回から3回に渡って、GitHub社がOSSとして公開しているオンラインスキーママイグレーションツール gh-ostについて紹介したいと思います。 はじめに、MySQLのオンラインスキーママイグレーションというとMySQL 5.6からオンラインDDLがあります。これにより、並列でDMLが実行されてもロックすることなくスキーマ変更が可能です。特に、MySQL 8.0からのInstance Add Columnは、テーブルをリビルドすることなく即時でカラム追加が完了するといううれしい機能です。 しかし、int型からbigint型へなどの型変更を伴うALTERステートメントなど、いくつかの操作は並列のDMLが許可されない、つまりそのテーブルが全体ロックされるような動作になります。加えて、レプリケーションの遅延が発生する可能性もあります。このように、操作の種類によってAlter中にできる動作が異な

                              第138回 オンラインスキーママイグレーションツール gh-ostを使ってみよう[その1] | gihyo.jp
                            • これだけは押さえておきたい、AWS移行全12ツール一挙紹介! | Amazon Web Services

                              AWS JAPAN APN ブログ これだけは押さえておきたい、AWS移行全12ツール一挙紹介! AWSには多くの移行関連ツールがあります。それらの概要と相関性及びリンクを1か所で簡潔にわかりやすくまとめてある日本語ページを提供したい! そこで今回はAWS のLead Migration PSAであるSatish Upretiを取材し、AWS移行に必要な12のツールの解説を一挙に掲載したいと思います。今後関連する日本語のサイトや追加Blogのリンクなども掲載&Updateしていきますのでぜひこちらのブログのブックマークをお願いいたします。 今回ご紹介するAWS移行関連の12のツールとサービスは以下の図のようにまとめられます。これらのAWS移行ツールを使うことでインフラストラクチャでのコスト削減、運用スピードと俊敏性の向上、オペレーショナルレジリエンス(業務回復力)の向上が見込めます。 AW

                                これだけは押さえておきたい、AWS移行全12ツール一挙紹介! | Amazon Web Services
                              • 不死身の言語「COBOL」とは? “Visual COBOL待望論”や“Goで脱COBOL”の動きも

                                関連キーワード プログラミング 金融機関の勘定系システムや製造業の生産管理システムなど、いまだにさまざまなシステムで使われているプログラミング言語「COBOL」。今回はこれまでに公開したTechTargetジャパンの記事の中から、COBOLに関する記事をピックアップして紹介します。 プレミアムコンテンツ(無料PDFブックレット) Javaのプロが「Kotlin」「COBOL」を学びたくなる理由《クリックで無料ダウンロード》 「Java」エンジニアの間で、次に習得すべきプログラミング言語の候補として「Kotlin」「COBOL」を検討する動きがある。その背景には何があるのか。JavaエンジニアがKotlinおよびCOBOLを習得する意義とは。 ダウンロードはこちら 連載:COBOLとの付き合い方 前編:「COBOL」プログラムが古くなっても動き続ける“切実な理由”《クリックで記事を表示》 組

                                  不死身の言語「COBOL」とは? “Visual COBOL待望論”や“Goで脱COBOL”の動きも
                                • ep.78 『賛成・反対それとも中立!?あなたはどっち派?TypeScriptを積極的に採用していくために必要なこと』 | UIT INSIDE

                                  ep.77 の延長戦として、@potato4d が、 @hyena_shoyo_kyo と @pittanko_pta に、 TypeScript を推進していくための考え方について話しました。 ゲスト紹介 shoyo.kyo @hyena_shoyo_kyo フロントエンド開発センター UIT 1室 UIT Dev 3 Team LINEポイントクラブとLINE LIVEのフロントエンドをメインに担当 amon.keishima @pittanko_pta LINE Growth Technology UIT Team LINEポイントクラブのフロントエンドをメインに担当 TypeScript 移行について『中立派』の意図とは TypeScript 賛成派と TypeScript 反対派が居るなか、中立の意図は どちらの気持ちもわかる 実際移行に踏み切れなかったときもあった が、自分の中

                                    ep.78 『賛成・反対それとも中立!?あなたはどっち派?TypeScriptを積極的に採用していくために必要なこと』 | UIT INSIDE
                                  • 大規模保険システムのマイグレーションへの挑戦 - シー・エス・エス イノベーションラボ(ブログ)

                                    はじめまして、保険太郎と申します。 今回は、数十年前から稼働する大規模保険システムのマイグレーション(Javaによるオープン化)という案件に携わった中での経験を少しだけお話ししたいと思います。 1.案件の背景 2.肥大化したシステムをどのようにリリースしていくか 3.案件に取り組むうえで大変だったこと、苦労したこと 4.開発をスムーズに行うために 5.さいごに 1.案件の背景 数十年前に構築された現行保険システムは既存商品の改定や新商品の追加、クレジットカードやQRコード決済といった支払方法の多様化などその時代にあったニーズに応えるため、何十年もかけて改修を続けてきたことにより、システムが肥大化しすぎたことで、新たなニーズにスムーズに対応することが厳しくなってきました。 そこで、Javaによるオープン技術を用いて、システム構成を見直し、よりわかりやすく、拡張性の高いシステムへと刷新すること

                                      大規模保険システムのマイグレーションへの挑戦 - シー・エス・エス イノベーションラボ(ブログ)
                                    • 大規模保険システムのマイグレーションに携わった話 - シー・エス・エス イノベーションラボ(ブログ)

                                      はじめまして、保険太郎と申します。 今回は、数十年前から稼働する大規模保険システムのマイグレーション(Javaによるオープン化)という案件に携わった中での経験を少しだけお話ししたいと思います。 1.大規模保険システムのマイグレーションへの挑戦 1-1.案件の背景 1-2.肥大化したシステムをどのようにリリースしていくか 2.案件に取り組むうえで起こった問題 2-1.既存システム全体の把握 2-2.海外メンバーとの伝達齟齬 3.さいごに 1.大規模保険システムのマイグレーションへの挑戦 1-1.案件の背景 数十年前に構築された現行保険システムは既存商品の改定や新商品の追加、クレジットカードやQRコード決済といった支払方法の多様化などその時代にあったニーズに応えるため、何十年もかけて改修を続けてきました。 その結果、システムが肥大化し、新たなニーズにスムーズに対応することが厳しくなってきました

                                        大規模保険システムのマイグレーションに携わった話 - シー・エス・エス イノベーションラボ(ブログ)
                                      1