ブックマーク / atmarkit.itmedia.co.jp (196)

  • 米Google SREディレクターに聞く、運用管理の意義、価値、役割

    Google SREディレクターに聞く、運用管理の意義、価値、役割:特集:情シスに求められる「SRE」という新たな役割(2) デジタルビジネスの競争が激化し、システム開発・運用の在り方がビジネスの成果に直結する状況となっている。こうした中で、運用管理者の役割も「担当システムの安定運用」から大きく変わりつつある。今回は、Googleの巨大なサービス群とインフラを支えているSRE――Site Reliability Engineer(サイト信頼性エンジニア)に、今、運用管理者が持つべき視点、マインドを探ってみた。 デジタル化の潮流で変わる、開発者、運用者の役割 テクノロジーの力で新たなビジネス価値を生み出すデジタルトランスフォーメーションが急速に進展している。IoT、X-Techに象徴されるデジタルビジネスの戦いも激化し、「ITは既存ビジネスの効率化・コスト削減」のためのものではなく、「収益

    米Google SREディレクターに聞く、運用管理の意義、価値、役割
    nishitki
    nishitki 2017/07/11
  • WannaCry騒動、Struts 2脆弱性、リオ五輪、そのとき「彼ら」は何をしていたのか

    WannaCry騒動、Struts 2脆弱性、リオ五輪、そのとき「彼ら」は何をしていたのか:「セキュリティリサーチャー」って何をする人?(1/2 ページ) サイバーセキュリティの重要性が増すにつれ、ネット上ではさまざまな脅威や脆弱性の情報があふれんばかりに増え続けている。そんな情報過多な状況から、有用な情報だけを選別し、正しく共有していくこともまた必要だ。WannaCry騒ぎ、Apache Struts 2脆弱性……そのとき「彼ら」は何をしていたのか。 「人材不足」「育成の必要性」などの課題と関連してひとまとめに語られがちな「セキュリティ人材」。しかし、セキュリティ対策の実装や運用だけでなく、内外との調整役、脆弱(ぜいじゃく)性検査とその結果に基づく設計、いざ問題が生じた際のレスポンス対応など、さまざまな役割が必要だ。業務内容は多岐にわたるため、1人で全てを担うのは難しい。セキュリティ担当

    WannaCry騒動、Struts 2脆弱性、リオ五輪、そのとき「彼ら」は何をしていたのか
    nishitki
    nishitki 2017/06/26
  • OracleからMySQLへ 「ストアドプロシージャ」の移行手順と工数評価

    OracleからMySQLへ 「ストアドプロシージャ」の移行手順と工数評価:実践 OSSデータベース移行プロジェクト(6)(1/3 ページ) 連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は、ストアドプロシージャの移行に関する難易度評価の手順を解説します。 連載バックナンバー 商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けする連載。前回は、「オブジェクト種別」「データ型」「ビューおよびストアドプロシージャのSQL」「テーブル及びインデックスのDDL」に関する移行コストの評価を行いました。 今回は、SQL以外の「ストアドプロシージャ」の移行評価手順を解説します。例とするシステムは前回と同様に、

    OracleからMySQLへ 「ストアドプロシージャ」の移行手順と工数評価
    nishitki
    nishitki 2017/06/22
  • AWSへの移行開始から3年半、ソニー銀行の「節約大作戦」があらためて教えてくれること

    ソニー銀行は、2013年末より、帳票管理やリスク管理、管理会計などの周辺系システムと開発環境の一部、および一般社内業務システムを、ITコストの最適化と俊敏性の向上を目的として、Amazon Web Services(AWS)へ段階的に移行してきた。ソニー銀行執行役員(システム企画部担当)の福嶋達也氏は同社のAWS利用について、2017年5月30日、AWS Summit Tokyo 2017のDive Deep Dayで語った。 「3年半経ってAWSをどう思うかといえば、『なぜもっと早く使わなかったのか』というのが率直な感想。また、日常に溶け込んでいて当たり前過ぎる存在になっており、『どうですか』と言われても答えにくいくらいだ」(福嶋氏) ソニー銀行では、2017年度末までに、一般社内業務システムおよび銀行業務周辺系システムのAWS移行を、概ね完了する見込みという。また、基幹系システムでのA

    AWSへの移行開始から3年半、ソニー銀行の「節約大作戦」があらためて教えてくれること
    nishitki
    nishitki 2017/06/21
  • グリーCTO藤本氏が明かす、エンジニアリングの観点をマネジメントに生かす具体的な方法

    グリーCTO藤氏が明かす、エンジニアリングの観点をマネジメントに生かす具体的な方法:一生、エンジニアべていける?(1/2 ページ) 開発の効率を高め、より良いサービスを実現し、価値を高めていくために、開発者には何ができるのか――そんなテーマを追求する「明日の開発カンファレンス」が2017年4月14日に開催された。その中から2つのセッションの模様を紹介する。 開発の効率を高め、より良いサービスを実現し、価値を高めていくために、開発者には何ができるのか――そんなテーマを追求する『開発リーダのための「明日の開発カンファレンス 2017」』が2017年4月14日に開催された。 より良い開発の実現に向け、DevOpsやCI/CD、アジャイルにテスト駆動開発といったキーワードが飛び交う昨今、オープンソースでさまざまなツールが提供されている。カンファレンスでは、まずは小さくてもいいので最初の一歩を

    グリーCTO藤本氏が明かす、エンジニアリングの観点をマネジメントに生かす具体的な方法
    nishitki
    nishitki 2017/05/30
  • あの日、Twitterのくじらが出なかったもう1つの理由

    社会を率いているリーダーは、いつの時代にも存在する。しかし、そのリーダーたちの顔ぶれは、毎年異なる。ここ数年、世界で注目されているリーダーの顔ぶれはどのように変化してきたのか。 社会を率いているリーダーは、いつの時代にも存在する。しかし、そのリーダーたちの顔ぶれは、毎年異なる。ここ数年、世界で注目されているリーダーの顔ぶれはどのように変化してきたのか。その移り変わりについて、漠然と想像することは可能だが、具体的に説明することは難しい。しかし、多くの活躍するリーダーの姿を間近で見てきた元日マイクロソフト会長、現慶應義塾大学大学院メディアデザイン研究科 古川享教授は、その変化を明確に示す。 今回は、2013年11月下旬から12月初旬にかけて古川氏が登壇した2つのイベントで語られた内容を合わせてレポートする。イベントは、慶應義塾大学大学院メディアデザイン研究科が主催した講演会「メディアイノベー

    あの日、Twitterのくじらが出なかったもう1つの理由
    nishitki
    nishitki 2017/04/17
  • 減り続ける利用可能メモリ……そしてついにリブート!

    減り続ける利用可能メモリ……そしてついにリブート!:Linuxトラブルシューティング探偵団 番外編(2)(2/3 ページ) メモリが足りなくなるとOSってハングアップするの? まずは、そもそもの疑問を整理しておきましょう。 お客さまは「メモリが足りなくなってリブートに至った」といっています。ですが今回の場合は、メモリ不足自体がリブートに直結したのではなく、ハングアップしていたところをASRによってハードウェア的に落とされたことが分かっています。ですから、質的な疑問は「メモリ不足がOSハングアップを引き起こし得るか?」ということです。 そもそもハングアップとは、カーネルパニックなどを起こしてシステムがクラッシュしている場合と、何らかの原因で極端に動作が遅くなっている場合がありますが、残念ながら疑問に対する答えは「Yes」です。メモリ不足がOSのハングアップを引き起こすことはあります。 「そ

    減り続ける利用可能メモリ……そしてついにリブート!
    nishitki
    nishitki 2017/04/13
  • 「Deep Learningをサービスに導入したい!」人に周囲が泣かされないために

    リクルートテクノロジーズにおける検索改善施策の事例を通じて、Deep Learningをはじめとした機械学習の強みと限界を探る連載「機械学習活用プロジェクト大解剖」。 前回は、検索改善のためのアーキテクチャ(QueryRewriter)とDeep Learningを導入する動機を紹介しました。今回は、「Deep Learningの導入のために何が必要であり、なぜQueryRewriterが開発されたのか」について解説します。 より具体的な改善事例は次回解説します。 機械学習を活用しやすくする開発・運用体制――2つのアンチパターン まず、「とにかくDeep Learningを使いたい!」というようなデータサイエンティストに周囲を泣かされないための仕組みと開発・運用体制について考えます。 新しい技術を導入する際は、何であれ慎重に進めた方がいいです。Deep Learningのような解釈可能性

    「Deep Learningをサービスに導入したい!」人に周囲が泣かされないために
    nishitki
    nishitki 2017/03/30
  • PCIe接続SSDに比べて14倍高速!アプリケーションの性能不足をHPE ProLiant Gen9 サーバー + NVDIMMテクノロジーが解決

    ビジネスに一層のスピードと柔軟性が求められる中で、機能がますます高度化・複雑化するアプリケーションの性能問題に悩むユーザー企業は多い。その点、日ヒューレット・パッカード(HPE)が2016年4月に発表した「HPE ProLiant Gen9 サーバー」の新製品は、その解決策となるスペックを有しているという。そのカギとなるのがHPEが業界に先駆けてサポートした不揮発性メモリ「NVDIMM」テクノロジーである。NVDIMMはどのようにアプリケーションの高速化をもたらすのか、その特長に迫る。 アプリケーション高速化のための要注目テクノロジー、不揮発性メモリ「NVDIMM」登場 企業間競争が激しい中で、競合他社の一歩先を歩み続けるためには、精度の高い情報に基づいたスピーディな意思決定と、顧客ニーズにリアルタイムに応えることが最重要ポイントとなる。 「企業がこうしたポイントを実現する第一歩として、

    PCIe接続SSDに比べて14倍高速!アプリケーションの性能不足をHPE ProLiant Gen9 サーバー + NVDIMMテクノロジーが解決
    nishitki
    nishitki 2017/03/20
  • アプリ開発者もインフラ管理者も知っておきたいサーバレスとAWS Lambdaの基礎知識

    Amazon Web Services(AWS)をはじめとするクラウドサービスの登場によって、システム開発や運用に対する考え方が大きく変わっています。 これまでのシステム開発といえば、自ら調達した物理サーバ上にOSやミドルウェア、アプリケーションを構築するものが主流でした。近年では、ファシリティ(データセンターの設備や資源)やハードウェア(サーバや物理ネットワーク)がクラウドプロバイダーによって提供されるクラウドサービスを活用し、ユーザーはOSレイヤー以上を構築するものが主流となりつつあります。 さらに、最近はプログラム開発とサービス連携のみでシステム開発が可能な「サーバレスアーキテクチャ」という新たな概念が登場しました。 連載「AWS Lambdaで始めるサーバレスアーキテクチャ入門」では、AWS上でサーバレスアーキテクチャを構築する方法を紹介します。なお、AWSを使ってシステムを構築

    アプリ開発者もインフラ管理者も知っておきたいサーバレスとAWS Lambdaの基礎知識
    nishitki
    nishitki 2017/02/23
  • アメブロでReactやIsomorphic Web Applicationを採用した理由――その成果と構成技術

    アメブロでReactやIsomorphic Web Applicationを採用した理由――その成果と構成技術:大規模ブログサイト表示速度改善 大解剖(1)(1/2 ページ) 2004年から続くブログサービス「アメブロ」が2016年9月にシステムをリニューアル。連載では、そこで取り入れた主要な技術や、その効果を紹介していく。初回は、Isomorphic Web Applicationについて。 2004年から続くブログサービスである「アメブロ」は、2016年9月にシステムをリニューアルしました。連載「大規模ブログサイト表示速度改善 大解剖」では、そこで取り入れた主要な技術や、その効果を紹介していきます。連載第1回では、Isomorphic Web Applicationについてお伝えします。 Amebaでは、これまでリッチなユーザー体験を実現するために、さまざまな取り組みをしてきました

    アメブロでReactやIsomorphic Web Applicationを採用した理由――その成果と構成技術
    nishitki
    nishitki 2017/02/13
  • 米フェイスブック、時系列データベースBeringeiをオープンソース化

    米フェイスブックは2017年2月3日(現地時間)、同社が開発したインメモリ時系列データベース「Beringei」をブログポストで説明、同ソフトウェアを最近オープンソース(BSDライセンス)で公開したことを紹介した。 米フェイスブックは2017年2月3日(現地時間)、同社が開発したインメモリ時系列データベース「Beringei」をブログポストで説明、同ソフトウェアを最近オープンソース(BSDライセンス)で公開したことを紹介した。 「Beringeiは現時点で、ユニークな時系列データを最大100億件格納し、毎分1800万件のクエリに応えられる。Facebookにおけるほとんどのパフォーマンスモニタリングおよびヘルスモニタリングを担っている。エンジニアやアナリストは、正確なリアルタイムのデータを活用し、迅速な決定ができるようになっている」と、ジャスティン・テラー(Justin Teller)氏は

    米フェイスブック、時系列データベースBeringeiをオープンソース化
    nishitki
    nishitki 2017/02/07
  • @IT:Linuxでは表示できないWebサイトがある

    Linuxでは、キヤノン(http://canon.jp/)や佐川急便の荷物問い合わせシステム(http://k2k.sagawa-exp.co.jp/)など、特定のWebサイトが表示できないことがある。これは、ECN(Explicit Congestion Notification)という仕組みを経路中のルータがサポートしていないことが原因だ。 ECNは、経路の混雑具合をルータがクライアントに通知する機能だ。経路が混雑している場合は送出データのサイズを小さくし、空いていれば送出データのサイズを大きくして、効率的にデータを転送する。しかし、ENCをサポートしていないルータに対してLinuxがENCオンのモードで通信を行うと、ルータからのリプライがないため通信できなくなってしまう。 Linuxは、カーネル 2.4から「CONFIG_INET_ECN」というコンパイルオプションをサポートした。

    nishitki
    nishitki 2017/01/31
    CONFIG_INET_ECN
  • 再送処理 - truncated binary exponential backoff

    それではイーサネットのCSMA/CD方式における送信処理の詳細について見てみよう。大まかに述べると、送信前にキャリアがないことを確認してから送信を開始し、衝突を検出した場合はランダムな時間だけ待ってから再送信を行うわけであるが、どのステーションにも平等に送信の機会を与え、再送信による衝突などが少なくなるように、さまざまな工夫が行われている。 送信処理 データをイーサネット フレームに加工し、アイドル状態がIFGの間続いたら送信を開始する(CSMA)。送信中もネットワーク媒体を監視し、衝突を検出したら送信を停止してJAM信号を送信する(CD)。JAM信号送信後はランダムな待ち時間待機し、再度送信処理を行う。同じフレームの送信に16回失敗した場合は、エラーとなりフレームを破棄する(バックオフ)。 1.フレーム・データの準備 上位層からのデータをイーサネット・フレームに加工する。フレームのデータ

    再送処理 - truncated binary exponential backoff
    nishitki
    nishitki 2017/01/30
    backoff
  • 運用自動化も障害対応も、全ては「現場のため」ではなく「顧客のため、ビジネスのため」

    運用自動化も障害対応も、全ては「現場のため」ではなく「顧客のため、ビジネスのため」:特集:情シスに求められる「SRE」という新たな役割(1) デジタルビジネスの激化を受けて、「いかにスピーディにITサービスを企画・開発するか」が重視されている。だが重要なのは「作ること」だけではない。リリースして以降、収益・ブランド向上はサービス運用を支える「運用管理の在り方」に掛かっている。特集では米グーグルが提唱するSRE――Site Reliability Engineerの概念を通じて「運用管理のビジネス価値」を再考。今求められる情シスの役割を考える。 ITサービスは「作った後」こそ重要 IoT、X-Techトレンドの高まりに象徴されるように、国内でも「テクノロジの力で新たな価値を生み出す」デジタルトランスフォーメーションが進んでいる。もはやUberなどの例を持ち出すまでもなく、“これまでになかっ

    運用自動化も障害対応も、全ては「現場のため」ではなく「顧客のため、ビジネスのため」
    nishitki
    nishitki 2017/01/16
  • セキュリティは、DevOpsやアジャイル開発にブレーキをかけるのか――マネーフォワード流DevOps実践のポイント

    セキュリティは、DevOpsやアジャイル開発にブレーキをかけるのか――マネーフォワード流DevOps実践のポイント:DevOps時代のテスト自動化カンファレンス(中編)(1/2 ページ) 2016年12月6日に開催されたセミナー「DevOps時代のテスト自動化カンファレンス~はやく、いいものを届けよう~」のレポート第2弾では、マネーフォワードの担当者を招いてのランチセッションの模様をはじめ、DevOpsとセキュリティ、テスト自動化の関係を解説していく。 市場ニーズを素早く形にし、「ビジネスの成果を獲得するまでのリードタイムを短縮する」上で重要な手法となる「アジャイル開発」や「DevOps」だが、これらの取り組みにおいて「テスト」というプロセスをどう組み込むかが「いいもの」を作れるかどうかの大きな分かれ目となる。管理すべきコード、テストすべきコードが増加する中で必要十分なテストを実施し、開発

    セキュリティは、DevOpsやアジャイル開発にブレーキをかけるのか――マネーフォワード流DevOps実践のポイント
    nishitki
    nishitki 2016/12/27
  • 「神エクセル」が役所ではびこる理由

    連載目次 河野太郎衆議院議員が行革推進部で文科省に対し「神エクセル」の全廃を指示したそうだ。河野議員人がそれをツイートしたことで「神エクセル」問題が再燃した。「再燃」というのは、以前、2013年に三重大学の奥村晴彦氏が問題提起したことで、Twitterなどで盛り上がった過去があるからだ。 参考リンク:「『ネ申 Excel』問題」 「神エクセル」とは、紙へ印刷することを前提に、セルの結合や罫線(けいせん)機能などをフルに使い、見栄えを優先して作ったExcelファイルのこと。「紙」が転じて「神」と表記するようになったネットスラングである。「ネ申エクセル」などと表現される場合もある。 「神エクセル」は、国会議員が役所に全廃を指示するくらいの大問題なのだろうか。恐らくデジタル系の職業に就いている人の多い@ITの読者であれば、間髪入れずに「大問題だ!」と叫ぶことであろう。例えば、次のようなシチュ

    「神エクセル」が役所ではびこる理由
    nishitki
    nishitki 2016/12/26
  • トレーサ関連に大きな進展、ftraceがデファクトに?(2/2) - @IT

    これはどういうことかというと、例2において、グループAが1GB、グループBが500MBで合計1.5GBのメモリを使用できるということです。 しかしながら、世の中にはユーザーXさんのメモリ使用量を全体で1GBに制限し、かつその中でもワークロードYのメモリ使用量は500MB以下に制限したい……というように、階層的に制約したいという状況がしばしばあります。 こういった要求に応えるため、Balbir Singhの手によりヒエラルキー機能が実装されました。上述の例の場合、グループAのmemory.use_hierarchyオプションをONにすることにより、ユーザーXとワークロードYの両方の制約を実現することができます。 この方式では、グループごとに動作を変更できるので非常に柔軟に制約条件を記述することができ、管理の手間を大幅に低減してくれると考えられています。 ■Mem+Swap controlle

    nishitki
    nishitki 2016/12/22
  • AbemaTV、サイバーエージェントの講演から探る、アジャイル開発成功の鍵と炎上しないための教訓

    AbemaTV、サイバーエージェントの講演から探る、アジャイル開発成功の鍵と炎上しないための教訓:DevOps時代のテスト自動化カンファレンス(前編)(1/2 ページ) “いいもの”を、より早く形にして市場に届ける際に欠かせないのが「テスト」だ。DevOpsやアジャイルといった開発スタイルの中で適切に、かつ効率よくテストを実施する秘訣とは何だろうか? @IT編集部が主催した「DevOps時代のテスト自動化カンファレンス~はやく、いいものを届けよう~」の講演から、そのヒントを紹介する。 市場ニーズを素早く形にし、「ビジネスの成果を獲得するまでのリードタイムを短縮する」上で重要な手法となる「アジャイル開発」や「DevOps」だが、これらの取り組みにおいて「テスト」というプロセスをどう組み込むかが「いいもの」を作れるかどうかの大きな分かれ目となる。管理すべきコード、テストすべきコードが増加する中

    AbemaTV、サイバーエージェントの講演から探る、アジャイル開発成功の鍵と炎上しないための教訓
    nishitki
    nishitki 2016/12/16
  • さらば、翻訳調の文章! 技術者向け校正ルール

    さらば、翻訳調の文章! 技術者向け校正ルール:誰にでも分かるSEのための文章術(8)(1/2 ページ) 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 第7回「専門用語は徹底的に「読み手指向」で書くべし」に引き続き、「語句の使い方」や「表記法」を解説します。今回は、技術者の文章にありがちな癖、「翻訳調」「漢字の多用」を、より読みやすい文章に修正する方法を提案します。 SEは、翻訳書・文書を読む機会が多い仕事です。専門書や技術書、開発業務を進める際の文書類を、英語の原文で読むこともしばしばあります。そのせいか、翻訳調の文章を記述してしまいがちです。 翻訳調、特に直訳調の表現は冗長です。読みにくいので使わないようにしまし

    さらば、翻訳調の文章! 技術者向け校正ルール
    nishitki
    nishitki 2016/12/03