タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

JavaとperformanceとAWSに関するraimon49のブックマーク (4)

  • PayPayカード、メインフレームの基幹システムをAWSに移行--業界で前例なき規模

    2015年にソフトバンクグループとなってからビジネスが大きく変わり、「『ネット屋の金融を目指す』というトップのビジョンの基でIT戦略も大きく変化した。あまり表明していないが、ITを大手ベンダーに丸投げせず自社でコントロールできるようにし、『ネット屋の金融』らしいプロダクトファーストな新しい金融サービスを目指すようになった。社内エンジニアでもシステム内部はベンダーにしか分からない状態で、エンジニアがものづくりに取り組むためにもシステム内部を理解していることが必要だった」(信太氏)という。 上述の経緯から同社の基幹システムは長年メインフレームで運用されてきたが、ビジネスが変わったことでモダナイズ(最新化)の必要性が高まり、まず2016年頃からアプリケーションを「COBOL」から「Java」に書き換える(リライト)改修を行った。このリライト作業は容易ではなく、「当時の担当者が既におらずドキュメン

    PayPayカード、メインフレームの基幹システムをAWSに移行--業界で前例なき規模
    raimon49
    raimon49 2023/04/22
    マルチAZ構成だと決済処理が10倍近く遅延するから許容できなかったのか。楽天KCから分離されてSB系に収まってるPayPayカードって会社の流れも何だか面白い。
  • TypetalkのEC2インスタンスをインテルプロセッサからARMベースのAWS Graviton2に完全移行。性能向上と費用削減を実現 | 株式会社ヌーラボ(Nulab inc.)

    TypetalkのEC2インスタンスをインテルプロセッサからARMベースのAWS Graviton2に完全移行。性能向上と費用削減を実現 はじめに こんにちは。SREの二橋です。最近の楽しみは、キャンプと釣りの動画を見ながら、お家で妄想を膨らませることです。 この度、TypetalkのEC2のインスタンスをインテルプロセッサを搭載したM5系からARMベースのAWS Graviton2を搭載したM6g系に完全移行しました。そこで、Graviton2の概要から移行しようと思った理由、作業内容、移行の効果などをお伝えしたいと思います。 AWS Graviton2とは? Graviton2はAWSがArm Neoverse コアをベースに独自開発したプロセッサです。2020年夏にAmazon EC2で一般用途向け(M6gとM6gd)、コンピューティング最適化(C6gとC6gd)、メモリ最適化(R6

    TypetalkのEC2インスタンスをインテルプロセッサからARMベースのAWS Graviton2に完全移行。性能向上と費用削減を実現 | 株式会社ヌーラボ(Nulab inc.)
    raimon49
    raimon49 2020/09/24
    JVMで走るアプリケーションだと移行し易いとうのは確かにありそう。Gatlingのレポート画面は見易くて好き。
  • Docker で「速くてウマイ」な CI 環境を構築するための 5 つの Tips | 株式会社ヌーラボ(Nulab inc.)

    Docker 社のユースケースでもあげられているように、CI/CD で Docker を使うというのは、プロダクションシステム以外で Docker の特性を活用できる良い場所だと考えています。ヌーラボではBacklog でのプルリクエストの提供以降、CI のジョブの実行のために Docker を利用しています。ここではその運用から学んだ5つの Tips を紹介したいと思います。 ヌーラボの CI 環境の全体図 これがヌーラボの CI 環境の全体図です。 CI には Jenkins を利用しており、Jenkins のジョブのトリガーとなるのは左側の Backlog や Typetalk です。実際には Jenkins Backlog Plugin や Jenkins Typetalk Plugin を利用してジョブを処理しています。これらのプラグインの詳細についてはブログ末に参照先をのせて

    Docker で「速くてウマイ」な CI 環境を構築するための 5 つの Tips | 株式会社ヌーラボ(Nulab inc.)
  • NetflixのAPI最適化

    先月1ヶ月間に渡って、Netflixは同社が1年以上前に始めたAPI最適化に関する話を発表した。当初は通信を少なくしペイロードのサイズを小さくすることで性能の最適化しようとしていた[1]が、1年にわたる再設計の結果、APIの開発と運用を分散化しサービス層は非同期になった。再設計の第一の特徴はクライアントとサーバの責任の境界[2]を再定義したことだ。こうすることでコンテンツのフォーマッティングなどきめ細かいカスタマイズが可能になり、Netflixに接続する多様なクライアントデバイス間の差異(メモリ、キャパシティ、ドキュメント配信、モデル、ユーザインターフェース)に対処できる。 InfoQはNetflixのシニアソフトウエアエンジニアであるBen Christensen氏に設計の詳細について話を聞いた。 InfoQ: 1年前、性能最適化を始めたころのNetflix APIのアーキテクチャを教え

    NetflixのAPI最適化
    raimon49
    raimon49 2015/03/29
    one-size-fits-all (OSFA) なアプローチをやめて動的エンドポイントで最適化。
  • 1