並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 136件

新着順 人気順

大規模システムの検索結果1 - 40 件 / 136件

  • これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」

    Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia

      これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」
    • 大規模システム開発案件のデスマーチは、どうしてこんなにつらいのか - あいむあらいぶ

      かるび(@karub_imalive)です。 この春までSI業界にいたので、たびたび大型システム開発案件の大規模炎上を見てきました。そして、ここ最近はみずほ銀行のシステム統合案件が厳しいようです。 2012年頃からスタートし、一昨年くらいからヤバイんじゃないの?と言われていた案件がどうも最終局面な感じになってきているようですね。 規模的に見ても、大きすぎて後戻りできないっぽいので、カネと時間がいくらかかっても最後までやりきるしかなさそう。しかし、みずほ社内オトシマエとしてたくさんの悲しい人事異動が発令されることでしょう・・・。(まぁ、今回はソースがまとめサイトやマイナー雑誌の抄訳なので、詳細については続報を見守りたいところですが・・・) さて、プロジェクトの炎上にも色々ありますよね。大きい案件なら数千人規模から、小案件なら2~3人規模のプロジェクトまで、規模を選ばず、炎上するときは炎上する

        大規模システム開発案件のデスマーチは、どうしてこんなにつらいのか - あいむあらいぶ
      • Twitterにおける大規模システム構築、3つの原則

        4月に米サンタクララで行われたMySQL Confernce & Expo 211では、TwitterのJeremy Cole氏が「Big and Small Data at @Twitter」と題して、同社のシステムにおける原則とシステム構成について紹介したプレゼンテーションが行われました。 1日に1億5000万以上のツイートが行われているTwitterのシステムはどのように構築されているのか、その内容を紹介しましょう。 Twitterにおける原則 TwitterのJeremy Cole氏。

          Twitterにおける大規模システム構築、3つの原則
        • Twitterの大規模システム運用技術、あるいはクジラの腹の中(前編)~ログの科学的な分析と、Twitterの「ダークモード」

          Twitterの大規模システム運用技術、あるいはクジラの腹の中(前編)~ログの科学的な分析と、Twitterの「ダークモード」 先週の6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」が開催されていました。 その中で、TwitterのJohn Adams氏がTwitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」(クジラの腹の中:Twitterでの運用)が行われています。Twitterのような大規模かつリアルタイムなWebサイトの運用とはどういうものなのでしょうか? 公開されているセッションの内容を基に概要を記事で紹介しましょう。システム管理者の新たな役割、Railsの性能の評価、Bittorrentを使った

            Twitterの大規模システム運用技術、あるいはクジラの腹の中(前編)~ログの科学的な分析と、Twitterの「ダークモード」
          • FacebookにおけるMySQLを用いた大規模システムアーキテクチャの現実~MySQL Connect 2013

            米オラクルが主催するMySQLのイベント「MySQL Connect」が9月21日から23日まで、サンフランシスコで開催されました。Oracle OpenWorld、JavaOneとの同時開催でした。 基調講演の1つには、MySQLのヘビーユーザーであるFacebookのHarrison Fisk氏が登壇。FacebookにおけるMySQLの役割、大規模運用の背景などを紹介しています。その内容をダイジェストで紹介しましょう。 MySQL@Facebook Lots and lots of small data Harrison Fisk氏。 Facebookでデータパフォーマンスチームのマネージャをしている。社内ではMySQLはもちろん、HBase Hadoopなどにも関わっている。 まずは、どんな種類のデータをMySQLで扱っているのかについて。 Facebookとは基本的にグラフだ。グ

              FacebookにおけるMySQLを用いた大規模システムアーキテクチャの現実~MySQL Connect 2013
            • 大規模システムでの Linux のメモリ管理

              (This post is also available in English.) この記事は Linux memory management at scale を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。 cgroup2 プロジェクトでの私の仕事の一部として Linux システムのリソース管理についてエンジニアと話すことに多くの時間をかけてきました。 これらの会話を通じてどんどん明らかになってきた 1 つの事実は多くのエンジニアは、シニア SRE たちでさえも、 Linux のメモリ管理についていくつかのよくある誤解を持っていて、そしてそれが彼らがサポートするサービスやシステムが本来確実に稼働したり効率的

                大規模システムでの Linux のメモリ管理
              • グーグルが構築した大規模システムの現実、そしてデザインパターン(1)~MapReduce編

                グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」(グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性)という講演を、6月に行われたACM(米国計算機学会)主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 グーグルはどのようにして大規模分散システムを構築してきたのか、そして、そこからどのようなことを学んだのかが語られていますし、後半では大規模分散システムのデザインパターンという、非常に興味深いノウハウも公開している、非常に情報量の多い講演です。 その講演の内容を、全部で4つの記事、MapReduce編、BigTable編、教訓編、デザイン

                  グーグルが構築した大規模システムの現実、そしてデザインパターン(1)~MapReduce編
                • Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」

                  Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」 米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」の、Twitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」(クジラの腹の中:Twitterでの運用)を紹介をしています。 この記事は「「Twitterの大規模システム運用技術、あるいはクジラの腹の中(前編)~ログの科学的な分析と、Twitterの「ダークモード」」の続きです。 Twitterのサブシステム「loony」「Murder」「memcached」 ここからはTwitterのサブシステムについて紹介しよう。 T

                    Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」
                  • Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog

                    Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画(第1

                      Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
                    • 金融界の福島第一原発、みずほ銀行の大規模システム障害という地獄の1週間 : 市況かぶ全力2階建

                      反AIと反原発、反AIの旗振り役の木目百二さんと反原発活動家の鴨下全生さんのせいで相性良く結びついてしまう

                        金融界の福島第一原発、みずほ銀行の大規模システム障害という地獄の1週間 : 市況かぶ全力2階建
                      • 大規模システムの保守における技術的負債とチームのモラル

                        Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

                          大規模システムの保守における技術的負債とチームのモラル
                        • 1000 台超の大規模システムにおける Solaris NFS 実装の問題

                          藤原 克則 ( FUJIWARA Katsunori ) 前職で、 HPC ( High Performance Computing ) 系システムのために Solaris 向けファイルシステムを実装したのを機に、 OpenSolaris 勉強会に参加。 「入門Mercurial Linux/Windows対応」、 「俺のコードのどこが悪い?―コードレビューを攻略する40のルール」、 「アセンブラで読み解くプログラムのしくみ」 といった書籍の執筆や、 技術系ウェブ媒体への記事の寄稿といったことも。

                          • 次期全銀システムに影響か、1973年の稼働以来初の大規模システム障害

                            全国銀行資金決済ネットワーク(全銀ネット)は2023年10月10日午前、銀行間送金を担う「全国銀行データ通信システム(全銀システム)」で他行宛ての振り込みができないトラブルが発生したと発表した。計画停止を除き、全銀システムで顧客に影響が出るシステム障害が発生したのは、1973年の稼働以来、初めて。2027年の稼働を見込む次期全銀システムの開発にも影響を与えそうだ。

                              次期全銀システムに影響か、1973年の稼働以来初の大規模システム障害
                            • 大規模システムにおける5つのログ転送パターン

                              成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。

                                大規模システムにおける5つのログ転送パターン
                              • Ruby 2.1がガベージコレクションを変更,大規模システムでの批判に対処

                                Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

                                  Ruby 2.1がガベージコレクションを変更,大規模システムでの批判に対処
                                • Deep Dive 大規模システムアーキテクチャ/開発組織エンジニアリング / Deep Dive Large-Scale System Architecture, Development Organization Engineering

                                  学生向けのイベント技育祭2024にて、大規模システムにおけるアーキテクチャの触りをお話したものです。 ビギナー向けなのでそれほど深いお話はしておりません。 【アブストラクト】 本トークでは大規模システムアーキテクチャで考慮すべき事柄とそれを実現する技術スタックや運用システムを深堀りし、それらを実現するための組織の構築をアーキテクト視点でお話します。大規模システムならでは難解な課題とそれを乗り越えるエンジニアリングの力の片鱗をキャッチアップしましょう。 詳細は以下をどうぞ。 https://talent.supporterz.jp/geeksai/2024spring/ # URL YouTube: https://www.youtube.com/c/narusemi HomePage: https://nrslib.com Twitter: https://twitter.com/nrsl

                                    Deep Dive 大規模システムアーキテクチャ/開発組織エンジニアリング / Deep Dive Large-Scale System Architecture, Development Organization Engineering
                                  • グーグルが構築した大規模システムの現実、そしてデザインパターン(4)~デザインパターン編

                                    グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」(グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性)という講演を、6月に行われたACM(米国計算機学会)主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 講演の内容を4つの記事(MapReduce編、BigTable編、教訓編、デザインパターン編)で紹介しています。この記事は教訓編の続き、デザインパターン編です。 大規模システムデザインの指針 よりよく使ってもらうためのインフラのデザインと開発方法を考えてみよう。 インフラに対する機能の要望についてさまざまなグループと話すと、多くのリクエ

                                      グーグルが構築した大規模システムの現実、そしてデザインパターン(4)~デザインパターン編
                                    • メルカリの大規模システムを安定運用へと導いた『DevOps』とは!? | dots. CONFERENCE SPRING 2016 | THE LANCER

                                      大規模システムに携わるエンジニア必見! メルカリが導入した安定運用のための技術『DevOps』というバズワードはどこかあいまいで、つかみどころがないと思っている方も多いことでしょう。運用と開発を一体化するという概念に厳密な定義はなく、どのように実務に落とし込めばよいのかが漠然としているからです。 しかし、急成長したメルカリの大規模システムを支えるSREという役割を持つエンジニア佐々木健一氏の語る奮闘から、DevOpsの本質が見えてくるのではないでしょうか。DevOpsで実現した大規模システムを安定して運用する仕組み作りをご紹介いたします。 テーマ:『メルカリDevOps物語 – 俺たちの戦いはこれからだ -』 メルカリDevOps物語 ー 俺たちの戦いはこれからだ ー メルカリはサービス開始が2013年と歴史は浅いのですが、アプリが急成長しユーザーが増えて、いろいろ困ったことがあったのでそ

                                        メルカリの大規模システムを安定運用へと導いた『DevOps』とは!? | dots. CONFERENCE SPRING 2016 | THE LANCER
                                      • 【MySQLウォッチ】第7回 大規模システムを支えるMySQLのレプリケーション機能:ITpro

                                        このところ楽天をはじめとして,MySQLを活用した大規模な事例が増えている(関連記事)。このような大規模,かつサービス停止の許されないシステムを支えているのが,MySQLのレプリケーション機能である。 「レプリケーション」とは,対象物とまったく同じ物を製作する処理だ。同じような意味に「ミラー」があるが,意味するところは物理的なコピーである。「レプリケーション」は,論理的な複製であり,対象物の全体や一部といった範囲を限定できる点が異なる。 このような機能は,大がかりな準備と高度な技術が必要と考えている方も多いだろう。しかし,MySQLのレプリケーション機能は,非常に簡単に利用することができる。今回は,現行バージョンでも利用可能なレプリケーション機能を解説する。 Masterの更新がSlaveに反映される MySQLのレプリケーション機能は,MasterとSlaveに役割が分かれる(図1[拡大

                                          【MySQLウォッチ】第7回 大規模システムを支えるMySQLのレプリケーション機能:ITpro
                                        • 第8回 Perlによる大規模システム開発・設計のツボ(1) | gihyo.jp

                                          本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはmixiの広木大地さんで、テーマは「大規模システム開発・設計のツボ」です。 仕事やOSS(Open Source Software)プロジェクトでPerlを用いた多人数開発をするにあたって気をつけるべきことや、品質を維持するためのノウハウを、国内最大級のPerlシステムであるmixiの事例をベースに紹介します。コーディング上の命名に関する考え方から、大規模アーキテクチャの設計や品質の数値化まで、ミクロからマクロに至るポリシーやテクニックを駆け足で解説します。 なお、今回の内容は(⁠株⁠)ミクシィの2010年度の新卒エンジニア技術教育メニューからの抜粋になります。これからPerl をはじめとするLL(Lightweight Language、軽量言語)を仕事で使うというフレッシュエンジニアのみなさんにも、ぜひご一

                                            第8回 Perlによる大規模システム開発・設計のツボ(1) | gihyo.jp
                                          • アメブロの大規模システム刷新と それを支えるSpring

                                            http://www.slideshare.net/lamanotrama/mogilefsprivate-s3 とワンセットの発表となります

                                              アメブロの大規模システム刷新と それを支えるSpring
                                            • グーグルが構築した大規模システムの現実、そしてデザインパターン(3)~教訓編

                                              グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」(グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性)という講演を、6月に行われたACM(米国計算機学会)主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 講演の内容を4つの記事(MapReduce編、BigTable編、教訓編、デザインパターン編)で紹介しています。この記事はBigTable編の続き、教訓編です。 大規模分散処理システムの構築から学んだこと ここからは、グーグルがたくさんのシステムを経験して学んだことと、それらのデザインパターンなどを紹介していきたい。 まず、大きく複雑な

                                                グーグルが構築した大規模システムの現実、そしてデザインパターン(3)~教訓編
                                              • Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26

                                                「Spring Fest 2018」で発表した資料です。 http://springfest2018.springframework.jp/ Read less

                                                  Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26
                                                • 大規模システムのリプレイスを2度経験したPMが語るシステム移行プロジェクトで重要なこと - JMDC TECH BLOG

                                                  JMDCの開発本部データ基盤開発部の新倉です。JMDCには大型案件に自由度高く取り組める環境があります。今回は私が実際に経験したDWHシステムの2度のリプレイスの事例をお伝えします。1度目はPL(プロジェクトリーダー)、2度目はPM(プロジェクトマネージャー)としてプロジェクトに参画。その経験からシステム移行プロジェクトを成功に導くポイントを解説します。 <プロフィール>※執筆当時 新倉 裕一郎(にいくら ゆういちろう)データウェアハウス開発部 データレイクグループ グループリーダー 新卒でソフトウェア会社に入社。大手ベンダー企業の介護パッケージソフト製造などの開発業務に従事。その後、SaaS型CRMサービスを展開するベンチャー企業に転職し、2015年5月に日本医療データセンター(現JMDC)入社。レセプトDWHシステムを担当し、2度のリプレイスを経験。現在はレセプトDWHシステムの保守開

                                                    大規模システムのリプレイスを2度経験したPMが語るシステム移行プロジェクトで重要なこと - JMDC TECH BLOG
                                                  • 大規模システム運用でpuppetやchefだけでは解決しづらいことを解決するMCollective! - よかろうもん!

                                                    もはや説明は不要かもしれませんが、"puppet"は、Puppet Labsが開発しているシステム運用管理ツールで、puppet管理下にあるサーバ群のシステムの状態を"あるべき状態"に保つための補助ツールです。 chefもpuppetと同等の機能を持ち、システムの運用管理をするには大変便利ではありますが、管理するサーバ台数が増加してくると、chef/puppetだけでは解決しづらいことも発生し始めます。 例えば、数百台のサーバの運用管理をしていたら、その中の一部だけサーバの状態が不安定になり、daemonが停止してしまったり、予期せぬレスポンスを返してしまったりする事態に遭遇することが稀にあります。 他にも、特定のロケールに配置してあるサーバでのみ、何かしらの処理を1度だけ実行しなければならないと事態も発生しがちです。 そのような場合は、puppetを利用して状況確認や処理の実行をすること

                                                      大規模システム運用でpuppetやchefだけでは解決しづらいことを解決するMCollective! - よかろうもん!
                                                    • 超大規模システム経験者が考える、攻めの開発を続けるために大切なこと| PLAID engineer blog

                                                      品質重視の超大規模システム開発経験からスピード重視の開発する環境に転職し、大規模システムの観点から攻めのスピード開発を止めないために考察した記事です。

                                                        超大規模システム経験者が考える、攻めの開発を続けるために大切なこと| PLAID engineer blog
                                                      • グーグルが構築した大規模システムの現実、そしてデザインパターン(2)~BigTable編

                                                        グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」(グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性)という講演を、6月に行われたACM(米国計算機学会)主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 講演の内容を4つの記事(MapReduce編、BigTable編、教訓編、デザインパターン編)で紹介しています。この記事はMapReduce編の続き、BigTable編です。 分散処理に対応するBigTable 次はBigTableの説明に移ろう。BigTableは、大規模分散の半構造化データストアシステムだ。 グーグルでは多くの構造的

                                                          グーグルが構築した大規模システムの現実、そしてデザインパターン(2)~BigTable編
                                                        • 大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ

                                                          モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか?という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは?」という結論に落ち着いた話をする。 はじまり ちょっとしたシナリオを想像してみよう。 プロジェクト立ち上げ期 「最近のトレンドはレイヤードアーキテクチャだ!」 そう言って、プロジェクトはスタートした。 . ├── application │ ├── xxx_usecase.go │ ├── xxx_repository.go │ ├── yyy_usecase.go │ └── yyy_repository.go ├── domain │ ├── xxx.go │ └── yyy.go ├── infrastructure │ └── xxx_

                                                            大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ
                                                          • 大規模システム障害、世界数千件に影響 1500億円損失も - 日本経済新聞

                                                            【ニューヨーク=白岩ひおな】8日に起きた米fastly(ファストリー)による世界的な大規模システム障害で、ウェブサイトの閲覧不能や取引の一時停止に見舞われた企業や政府機関のサイトは数千件に上った。アマゾンやイーベイなど電子商取引(EC)企業のサイトも含まれ、世界の小売業に与えた損失は約1500億円超に上るとの試算もある。ウェブコンテンツを素早く配信できる利便性の裏で、サービスを提供する一部の企業

                                                              大規模システム障害、世界数千件に影響 1500億円損失も - 日本経済新聞
                                                            • ノンプログラミングで大規模システムを開発可能、ラクラスがフレームワーク「SQN」を発表

                                                              ノンプログラミングで大規模システムを開発可能、ラクラスがフレームワーク「SQN」を発表:SQNで開発した「ラクラス人事クラウドサービス」の販売も開始 ラクラスは、プログラミングを必要とせずに大規模情報システムを開発できるフレームワーク「SQN」を開発した。クラス図やフローチャート、各タスクに対するデータ操作をそれぞれ定義することで、所望の処理を実行させる。 ラクラスは2018年5月10日、プログラミングを必要とせずに大規模情報システムを開発できるフレームワーク「SQN」を開発したと発表した。同時に、同フレームワークを用いて開発した「ラクラス人事クラウドサービス」の販売も開始した。SQNは、ラテン語の「Sine Qua Non」(シン・クア・ノン)の頭文字をとったもので、「必要不可欠なもの」を意味する。 SQNでは、データ構造を定義したクラス図や、業務プロセスを定義したアクティビティー図(フ

                                                                ノンプログラミングで大規模システムを開発可能、ラクラスがフレームワーク「SQN」を発表
                                                              • 三菱東京UFJ銀行,オープンソースのJava開発フレームワークSeasar2を大規模システムの構築に採用

                                                                <b>左から,開発プロジェクトに参加している木村雅彦氏,商用サポートを提供している飯田哲夫氏,Seasar2開発者の比嘉康雄氏(いずれもISID)</b> 電通国際情報サービス(ISID)は2006年7月19日,三菱東京UFJ銀行とUFJIS(三菱UFJフィナンシャル・グループのシステム子会社)が,国産のオープンソースJava開発フレームワークであるSeasar2を,大規模ミッション・クリティカル・システムの構築に採用したと発表した。UFJISがシステム・インテグレーションを担当し,ISIDがシステム開発を行う。なお,ISIDには,Seasar2のチーフ・コミッタである比嘉康雄氏(写真右)が在籍している。 Seasar2を採用したのは,三菱東京UFJ銀行の市場系取引のリスク計算を行うシステムの開発。日本ヒューレット・パッカードのHP ProLiant BL20pを52台連携させたブレード・

                                                                  三菱東京UFJ銀行,オープンソースのJava開発フレームワークSeasar2を大規模システムの構築に採用
                                                                • スクープ 出光で大規模システム障害、ガソリン代誤請求も

                                                                  出光興産で大規模なシステム障害が起きていることが日経ビジネスの取材で6日、明らかになった。出光のPOS(販売時点情報管理)システムに不具合があり、顧客への請求書発行が遅れたり、誤った金額で顧客に代金を請求したりする例が相次いでいる。ガソリンスタンドなど販売店の中には、顧客からの支払いが滞り、資金繰りを懸念する声も出ている。

                                                                    スクープ 出光で大規模システム障害、ガソリン代誤請求も  
                                                                  • Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例

                                                                    Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例:先行事例に学ぶKubernetes企業活用の現実(2) 本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。今回は、リクルートテクノロジーズにおいて筆者が取り組んだ事例を基に、コンテナ仮想化技術を本番環境で利用する際の取り組み、成果と課題、「なぜ最終的にKubernetesを活用する決断に至ったか」を説明する。 コンテナ仮想化技術を本番環境で利用する際の3つのフェーズ 昨今、コンテナオーケストレーションツール「Kubernetes」に注目が集まっています。本連載「先行事例に学ぶKubernetes企業活用の現実」では、サービスの開発、提供のアジリティー向上の一助となることを目的として、企業にお

                                                                      Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例
                                                                    • 第8回 Perlによる大規模システム開発・設計のツボ(3) | gihyo.jp

                                                                      技術的負債の「見える化」 どのようなソフトウェアにも設計上のミスはあります。設計時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も、その次のサービスリリースでは設計上の修正を必要とするかもしれません。これらの変更への粘着性や複雑性のある状態を、「⁠技術的負債」と言います。 mixiでは技術的負債は長らく、コードレビューや技術力の高いエンジニアによる新機能リリース時の修正などで対応を行ってきました。しかし、これまでに紹介した「わかりやすいコードの指針」や「アーキテクチャパターン」をレビューや教育だけで維持することは、ソフトウェアが巨大になり、開発者数が増加するにつれて難しくなります。そのため現在では、ソフトウェアの設計品質評価を自動化するツール群を開発し、それらを用いて技術的負債を見える化し、計画的に解消していく試みを行っています。 コ

                                                                        第8回 Perlによる大規模システム開発・設計のツボ(3) | gihyo.jp
                                                                      • 第8回 Perlによる大規模システム開発・設計のツボ(2) | gihyo.jp

                                                                        mixiのアーキテクチャパターン 2011年4月現在、mixiは2004年2月のサービス開始から7年以上をかけて、最適化、バグ修正、新機能リリースなどを続けています。(⁠2)では、こういった状況の中で、安定したサービスをみなさんにお届けするために取り入れているアーキテクチャ設計上の工夫や、失敗を修正していくための品質評価手法を紹介します。 システムの境界と階層化 mixiでは個々の機能について、次のようなパッケージレイアウトを採用しています。 Mixi::Voice::* つぶやき機能に関するモジュール群 Mixi::Video::* ビデオ機能に関するモジュール群 Mixi::Diary::* 日記機能に関するモジュール群 Mixi::Home::* ホーム表示機能に関するモジュール群 以降では、これらのモジュールの集まりを「コンポーネント」と呼びます。これらのコンポーネントは、相互に連

                                                                          第8回 Perlによる大規模システム開発・設計のツボ(2) | gihyo.jp
                                                                        • ファミマで「大規模システム障害」が判明、スタッフ数千人の給与支払いに被害

                                                                          南アフリカ・ヨハネスブルグ出身。講談社「FRIDAY」、文藝春秋「週刊文春」記者を経て、ジャーナリストとして独立。日韓関係、人物ルポ、政治・事件など幅広い分野の記事執筆を行う。著書に『韓国人、韓国を叱る 日韓歴史問題の新証言者たち』(小学館新書)、『完落ち 警視庁捜査一課「取調室」秘録』(文藝春秋)など。スクープの裏側を明かす「元文春記者チャンネル」YouTubeにて配信中。Note https://note.com/akaishi01 Twitter:@red0101a DOL特別レポート 内外の政治や経済、産業、社会問題に及ぶ幅広いテーマを斬新な視点で分析する、取材レポートおよび識者・専門家による特別寄稿。 バックナンバー一覧 ファミリーマートで大規模なシステム障害が起きていることが、同社への内部取材で明らかになった。約7000店舗、数千人のアルバイトスタッフの給与支払いに影響が出て、

                                                                            ファミマで「大規模システム障害」が判明、スタッフ数千人の給与支払いに被害
                                                                          • TIS、COBOLの大規模システムをJavaに自動変換する移行支援サービス

                                                                            TISは2017年4月11日、メインフレームで稼働するメガステップクラスの大規模アプリケーションを、オープン環境に移行するのを支援する「Xenlon~神龍 マイグレーションサービス 」を4月から順次提供開始すると発表した。習得率が減少し保守要員の確保が難しいCOBOLの大規模アプリケーションを、技術者の確保が容易なJavaに移行することで、運用コストを低減して運用継続性を担保する。 高い再現性で業務ロジックのほぼ100%を自動変換できる独自ツール「Xenlon~神龍 Migrator C2J」を活用し、COBOLからJavaへの移行を支援するサービス。「アセスメントサービス」「マイグレーションサービス」「運用・保守サービス」「Cloud基盤移行サービス」「Cloud基盤プラットフォームサービス」の5つのメニューから構成される。 アセスメントサービスは、マイグレーションを検討するシステムを対

                                                                              TIS、COBOLの大規模システムをJavaに自動変換する移行支援サービス
                                                                            • 大規模システム構築に求められる自動化とChefの基本的な考え方とは

                                                                              システム構築・運用の問題 近年、HadoopやOpenStackといった大規模分散基盤が注目を集めています。それに伴い多数のサーバーを構築・運用する機会のある方も増えてきているのではないでしょうか。 筆者も以前、数百台のHadoopクラスタ構築を担当したことがあり、構築台数の多さと作業の煩雑さに愕然としました。特に以下の点が問題でした。 (1)設定ミスにより膨大な作業が発生するリスクがある 検証環境の構築で、当初筆者は同じようなサーバーの構築を何度も行っていました。同じ作業を何度も繰り返していると、すぐに作業がマンネリ化し集中力が続かなくなり、設定ミスが多くなりました。その様な設定ミスが致命的な場合は、切り分け作業や設定の見直し作業が発生します。最悪の場合、全サーバの設定を確認することも考えられます。 (2)全体の待ち時間が大きな時間のロスになる パッケージのインストールなどは待ち時間が1

                                                                                大規模システム構築に求められる自動化とChefの基本的な考え方とは
                                                                              • 大規模システム障害の舞台裏

                                                                                ここ最近、大規模なシステム障害が相次いでいるが、疑問に思うことがある。「なぜバックアップのシステムが働かないのか」という点だ。そこで、筆者は日経コンピュータで特集を企画し、20社近くを取材した。その結果、各企業は様々な想定外に見舞われ、システム障害が表面化し、さらにバックアップが無力化していたことが分かった。 今回、特集を執筆するにあたって、神戸新聞社、全日本空輸(ANA)、NTT地域会社、大垣共立銀行の4社を中心に取材をした。各社とも、ここ約半年の間に大きな障害に直面しており、バックアップのシステムも保有していた。しかし、バックアップが動くことはなかった。 その理由は、大きく3つに分けられる。1つめはバックアップが効かない「単一障害ポイント」でトラブルが発生したこと(神戸新聞社、大垣共立銀行)。2つめがバックアップ側にも問題がコピーされてしまったこと(NTT地域会社)。そして3つめがバッ

                                                                                  大規模システム障害の舞台裏
                                                                                • 大規模システムの開発を加速、CAがDevOpsに新ソリューション

                                                                                  大規模システムの開発を加速、CAがDevOpsに新ソリューション:CA World 2013レポート 少ない予算で、より速くアプリ開発と提供のサイクルを回す――。モバイル端末やソーシャル・ネットワークの普及でB2C、B2Bのインタラクションが増す中、特に決済系などEコマースで利用されているメインフレームを含む基幹システムのアプリ開発のスピードアップが急務となっている。現在、6~12カ月かかっている開発サイクルを数週間、あるいは数日へと加速することは可能だろうか? 2013年4月21日から3日間、CA Technologies主催で米ラスベガスで開催された年次プライベートイベント、CA Worldでは「モバイル」「DevOps」「クラウド」「SaaS」をキーワードに新たに買収もしくは投入されたソリューションの紹介が行われたが、ここでは主にDevOps関連に焦点を当ててレポートをする。 メイン

                                                                                    大規模システムの開発を加速、CAがDevOpsに新ソリューション