タグ

ブックマーク / www.intellilink.co.jp (23)

  • 自然言語処理モデル「GPT-3」の紹介 | NTTデータ先端技術株式会社

    1. 概要 近年、ディープラーニングの自然言語処理分野の研究が盛んに行われており、その技術を利用したサービスは多様なものがあります。 当社も昨年2020年にINTELLILINK バックオフィスNLPという自然言語処理技術を利用したソリューションを発表しました。INTELLILINK バックオフィスNLPは、最新の自然言語処理技術「BERT」を用いて、少ない学習データでも高精度の文書理解が可能です。また、文書の知識を半自動化する「知識グラフ」を活用することで人と同じように文章の関係性や意図を理解することができます。INTELLILINK バックオフィスNLPを利用することで、バックオフィス業務に必要となる「文書分類」「知識抽出」「機械読解」「文書生成」「自動要約」などさまざまな言語理解が可能な各種AI機能を備えており、幅広いバックオフィス業務の効率化を実現することが可能です※1。 図:IN

    自然言語処理モデル「GPT-3」の紹介 | NTTデータ先端技術株式会社
  • GNU sed 4.3登場 - 開発に携わって | NTTデータ先端技術株式会社

    Tweet GNUの開発に関わるようになったきっかけ 私がGNUの開発に関わるようになったきっかけは、2010年頃当時のGNU grepの最新版2.5.4が日語環境で極端に遅かったことにあります。 コラムをご覧になられている皆さまも手元に開発ツールがインストールされたUnix/Linuxを用意できるようでしたら、実際にgrep 2.5.4をGNUのサイトからダウンロード、インストールして、動かしてみてください。以下の検索を行うと、結果が返されるまでにかなり時間かかると思います。 $ gzip -cd grep-2.5.4.tar.gz | tar xf - $ cd grep-2.5.4 $ ./configure $ make $ yes $(printf %040d 0) | head -10000 >inp $ time -p env LC_ALL=ja_JP.utf8 grep

    GNU sed 4.3登場 - 開発に携わって | NTTデータ先端技術株式会社
  • Apache Sparkで始めるお手軽機械学習(Word2Vec編) | NTTデータ先端技術株式会社

    Apache Sparkと機械学習 当社のコラムでも既に何度か取り上げてきたが、Apache Sparkがいよいよ格的な流行の様子を見せている。Apache Sparkは下図のようなエコシステムを持っているが、特にその中でも、Spark Streamingによるリアルタイム処理とともに、MLlibによる機械学習処理が人気を博している。日ではHiveを用いてのバッチ処理高速化にてHadoopが広く使われるようになったが、Apache Sparkの場合は、リアルタイム処理・機械学習処理を糸口にパラダイムシフトが行われていると言っても過言ではないだろう。 (出典:Apache Spark公式サイト ) コラムではMLlibを用いての機械学習処理について簡単な使い方を説明するものとする。 Apache Sparkは分散メモリRDDを活用することで、特定のデータに対する繰り返し処理に向くアーキ

    Apache Sparkで始めるお手軽機械学習(Word2Vec編) | NTTデータ先端技術株式会社
  • 最終回「防災訓練ノススメ」 | NTTデータ先端技術株式会社

    Tweet セキュリティに関する問題が発生した時のために CSIRT (Computer Security Incident Response Team) の構築や、災害が発生した時のために事業継続計画 (Business Continuity Plan) を定めたり、標的型攻撃メールへの訓練を行ったりする組織は増えてきていると思います。 しかし、セキュリティインシデントでも災害でもないトラブルへの訓練状況についてはどうでしょうか?例えば、システムの構築時に SysRq-c を使った kdump 取得試験をするだけだったりとかいうことはないでしょうか?システムの応答が極端に遅くなった場合の対応手順について考えたことはありますでしょうか? kdump の取得には成功したものの、ファイルサイズが巨大すぎて、サポートセンターに送付する手段を用意できなかったというケースがありました。サポート対象外

    最終回「防災訓練ノススメ」 | NTTデータ先端技術株式会社
  • 第16回「 kernel-debug ノススメ」 | NTTデータ先端技術株式会社

    Tweet Linux カーネルの中には、カーネル内でのデッドロックやメモリリークなど、カーネル自身のデバッグを行うための様々な機能が含まれています。しかし、 kernel パッケージに含まれている普通のカーネルでは大部分が無効化されているため、実際に運用を開始してトラブルに遭遇するまで、カーネル自身のバグに気が付かないケースが多くあります。 RHEL の場合、多くのデバッグ機能を有効にした kernel-debug というパッケージも提供されています。 kernel-debug パッケージに含まれているデバッグ用カーネルを用いてシステムの構築時に試験を行うことで、運用開始後に遭遇する可能性のあるバグの一部を事前に見つけて対処を行うことができます。また、運用開始後でも、原因の究明に役立つことがあります。 kernel-debug パッケージのインストールは、以下に示すように yum コマン

    第16回「 kernel-debug ノススメ」 | NTTデータ先端技術株式会社
  • Apache Sparkで始めるお手軽リアルタイムウインドウ集計 | NTTデータ先端技術株式会社

    バッチを高速にした後はリアルタイムの世界へ! 現在、さまざまな業種の企業でビッグデータ分析の取り組みが行われている。ビッグデータへの最初の取っ掛かりは、既存のバッチ処理の高速化や、大量の業務データを用いた分析レポートの作成という企業が多いことだろう。そして、バッチ処理の高速化が一段落した次のステップとして、「リアルタイム処理」をテーマに掲げる企業も多いかと思われる。具体的には、 直近10秒間のトラフィックを集計したい。 直近10分間で自社商品がTwitterで話題になった回数を知りたい。 直近10時間での全店舗での来客数を集計したい。 といったリアルタイムなモニタリングを実現したくなるのではないだろうか?こういったモニタリング用の集計は、技術的には「ウインドウ集計(Time-Window Operation)」と呼ばれる。そこでコラムでは、近頃、「ポストHadoop」として話題のApac

    Apache Sparkで始めるお手軽リアルタイムウインドウ集計 | NTTデータ先端技術株式会社
  • 楽しい可視化 : elasticsearchとSpark Streamingの出会い | NTTデータ先端技術株式会社

    0. ログやデータを取得した後は? ログやデータの分析には、様々なアプローチが考えられるが、Apache Solrやelasticsearchといった全文検索エンジン製品にデータを蓄積し、その機能を用いて検索・集計・分析を行う方法がある。その際、データをそのまま蓄積するのではなく、各ツイート・各行に属性を付与(エンリッチメント)することにより、分析の幅は大きく広がる。 全文検索エンジンへのデータの投入では、Flume-ngやfluentdといったデータ収集製品を利用する実例が多い。しかし、リアルタイムにデータに対してエンリッチメントの前処理を行おうとした場合、処理が複雑になるにつれ、単体サーバーで動作するFlume-ngやfluentdでは処理能力が頭打ちになってくる。そこで、登場するのが、リアルタイムに大量のデータを処理することができるストリーミング処理系のビッグデータ関連技術である。

    楽しい可視化 : elasticsearchとSpark Streamingの出会い | NTTデータ先端技術株式会社
  • 第15回「フォールトインジェクションノススメ」 | NTTデータ先端技術株式会社

    Tweet 前回紹介した SystemTap は、システムの管理や保守を行う人にとってだけでなく、Linux カーネルの開発やシステムの開発を行う人にとっても有用なツールです。 SystemTap を使うと、任意の箇所に遅延を挿入したり、メモリーの内容を書き換えたりすることもできます。そのため、意図的に競合状態を発生させることで問題事象を再現させたり、意図的にエラー状態を発生させることでトラブルが生じないかどうかを試験したりすることができます。そこで、今回は SystemTap を用いて試験を行った事例について紹介したいと思います。 ここで紹介している内容は、トラブル発生時の対処フローを確認したい場合に試すことができます。例えば、フリーズ事象が発生した場合には、 SysRq キーを使って情報を取得する練習ができます。 また、 KernelOops イベントが発生した場合に備えて、 /pro

    第15回「フォールトインジェクションノススメ」 | NTTデータ先端技術株式会社
  • 緊急コラム: glibc 脆弱性( CVE-2015-0235 )の影響範囲の調査方法について | NTTデータ先端技術株式会社

    Tweet 先週公開された glibc の脆弱性について、管理されているサーバーへの影響の有無を気にされている方が多いと思います。そこで緊急コラムとして、脆弱性の見つかった関数が使われているかどうかを調査する方法について紹介します。 この脆弱性について調査するにあたり、 ステップ1: 脆弱性の見つかった関数を呼び出している可能性があるかどうか? ステップ2: 脆弱性の見つかった関数を呼び出している場合、脆弱性を攻撃するために任意の値を攻撃者が渡すことができるかどうか? ステップ3: 任意の値を攻撃者が渡すことができる場合、どのような被害が生じうるか? という3つのステップを考える必要があります。 ステップ1に関しては、 ライブラリを静的にリンクしたプログラムファイルは、この記事で紹介している方法では調査できない。 glibc 以外のライブラリを経由して呼び出している場合は調査手順が複雑にな

    緊急コラム: glibc 脆弱性( CVE-2015-0235 )の影響範囲の調査方法について | NTTデータ先端技術株式会社
  • 第14回「 SystemTap ノススメ」 | NTTデータ先端技術株式会社

    Tweet 今回は、カーネルに関するトラブル解析で大活躍する SystemTap についてです。SystemTap の使用を容認できるかどうかが問題事象の原因を究明できるかどうかに直結しそうな、切り札と言えるくらいに重要なツールです。導入手順と使い方については Red Hat 社のウェブサイトにある記事( https://access.redhat.com/ja/node/882873 )を参照していただくとして、ここでは実際の調査で使用できるサンプルを紹介したいと思います。 サンプル1:再起動要求をカーネルパニックに置き換える。 正常なシャットダウンシーケンスを伴わずにシステムが突然再起動するというのは、シリアルコンソールや netconsole を使ってカーネルメッセージの有無を確認することくらいしかできない、システム管理者にとって悩ましいトラブルです。しかし、SystemTap を容

    第14回「 SystemTap ノススメ」 | NTTデータ先端技術株式会社
  • 第13回「 TaskTracker ノススメ」 | NTTデータ先端技術株式会社

    Tweet 前回紹介した System Call Auditing にはいくつか不便な点があります。 例えば、システムコールに渡された数値ではない引数(文字列や構造体などへのポインタ)を数値として記録してしまうため、別の箇所でパス名として記録される一部の例外を除いて、数値ではない引数の内容を確認する目的では使えないという点があります。そのため、必要に応じて strace コマンドや ltrace コマンド、SystemTap などを併用して情報を取得することになります。ちなみに、 TOMOYOLinux では文字列や数値で表されるパラメーターを扱うことを意識しているので、取得できる項目は限られているものの、ソケットアドレス構造体の中に埋め込まれたIPアドレスとポート番号の組み合わせのような情報を取得することができます。 他にも、プロセスを特定するための手がかりが貧弱であるという点があります

    第13回「 TaskTracker ノススメ」 | NTTデータ先端技術株式会社
  • 第12回「 System Call Auditing ノススメ」 | NTTデータ先端技術株式会社

    Tweet 調査対象となるプロセスがすでに判明している場合の挙動を追跡するには strace を使用します。しかし、毎年数件あるトラブル問合せの一例なのですが、「誰かがプロセスにシグナルを送信して強制終了させてしまっている可能性がある」という場合には、全プロセスを調査対象にするために System Call Auditing を使用します。 ステップ1:監査の対象とするシステムコールを確認する System Call Auditing ではシステムコール名でルールを記述しますので、どのシステムコールを監査対象にするかを判断します。そのためには、audit パッケージのソースコードを確認します。 $ rpm -qf /sbin/auditd audit-2.3.7-5.el6.x86_64 $ yumdownloader --source audit-2.3.7-5.el6 $ rpm --

    第12回「 System Call Auditing ノススメ」 | NTTデータ先端技術株式会社
  • 第11回「 strace ノススメ」 | NTTデータ先端技術株式会社

    Tweet 今回は、プログラムが期待通りに動作しない場合に、特定のプロセスの挙動を追いかけるための手順について紹介します。 プロセスの挙動を追いかける方法にはいろいろあります。例えば、スクリプト言語で記述されたプログラムの挙動を追いかける場合、デバッグのための print 命令を挿入することもあるでしょう。でも、プログラムの種類によらずに挙動を追いかける場合、原則としてカーネルが提供する機能を使います。例えば strace コマンドを用いてシステムコールの呼び出し履歴を取得したり、 ltrace コマンドを用いてライブラリ関数の呼び出し履歴を取得したりします。また、対象となるプロセスが不明な場合には全プロセスを対象にするために System Call Auditing を使って履歴を取得したり、 SystemTap を使って任意の箇所で履歴を取得したりすることもあります。 今回は stra

    第11回「 strace ノススメ」 | NTTデータ先端技術株式会社
  • 第10回「ソースコード閲覧ノススメ」 | NTTデータ先端技術株式会社

    Tweet 今回は、ディストリビューションに含まれているプログラムのソースコードを確認するための手順について紹介します。 この連載は主に RHEL ユーザーを想定していますが、今回は業務利用している RHEL サーバー上で作業するのではなく、自分のデスクトップ PC 上に仮想化環境で動作する CentOS サーバーをインストールして自分で作業するというケースを想定しているため、 CentOS ユーザー向けの手順で紹介します。 まず、 yum コマンドを使って yum-utils パッケージと rpm-build パッケージをインストールしてください。(既にインストールされているようであれば、無視して次へ進んでください。) # yum -y install yum-utils rpm-build 次に、ソースコードパッケージをダウンロードするためのレポジトリとして、/etc/yum.repo

    第10回「ソースコード閲覧ノススメ」 | NTTデータ先端技術株式会社
  • 第9回「アップデートノススメ」 | NTTデータ先端技術株式会社

    Tweet 今回は、ソフトウェアのアップデートについての基礎知識について紹介します。 RHEL の基礎知識 RHEL とはソフトウェアの名前ではなく、ディストリビューションの名前です。 ディストリビューションとは、無数にあるソフトウェアの中から、当該ディストリビューションのサポート方針に従って選定されたソフトウェアのコレクションです。 RHEL のサポート方針については以下のページを参照ください。 Red Hat Enterprise Linux - Top Support Policies 殆どのソフトウェアにはメジャーバージョンとマイナーバージョンという区別があり、メジャーバージョンアップでは新機能の追加など大きな変更が生じるのに対し、マイナーバージョンアップではセキュリティ問題の修正や不具合修正など小さな変更のみが生じるという傾向があります。 RHEL に含まれるソフトウェアは、それ

    第9回「アップデートノススメ」 | NTTデータ先端技術株式会社
  • 第7回「 sosreport ノススメ」 | NTTデータ先端技術株式会社

    Tweet 前回は、 Bugzilla と Red Hat 社のサポートケースについて紹介しました。今回は、Red Hat 社のサポートケースを利用する際に添付することが多い sosreport について紹介します。 sosreport は、システムに問題が発生した時に、ログファイルや設定ファイルなどシステムの状態を把握するための情報を一括して取得するためのツールです。 サポートの担当者は、 sosreport コマンドを用いて取得した sosreport ファイルの内容を確認することで状況を把握し、次の行動を考えます。 sosreport を取得する上での注意点としては、以下の点が挙げられます。 カーネルモジュールの自動ロード CPU使用率とディスクI/O 取得するタイミング 含まれている内容 (1) カーネルモジュールの自動ロード sosreport コマンドを実行すると、内部で様々な

    第7回「 sosreport ノススメ」 | NTTデータ先端技術株式会社
  • 第6回「 Bugzilla ノススメ」 | NTTデータ先端技術株式会社

    Tweet 今回は、 Bugzilla について紹介します。 Bugzilla とは、不具合についての報告・修正を行うための枠組みです。 Red Hat 社の場合 Red Hat Bugzilla という名前のシステム( https://bugzilla.redhat.com/ 、 RHBZ と略されます)を利用しています。異なる枠組みを使っているディストリビューションもあり、例えば Ubuntu の場合 Launchpad という名前のシステム( https://launchpad.net/ 、 LP と略されます)を利用していますが、利用する上で大事なことは同様です。 RHBZ への登録を行う際に必要な情報を以下に示します。 Product: 対象となる製品名(例えば Red Hat Enterprise Linux 7 ) Component: 対象となるパッケージ名(例えば ker

    第6回「 Bugzilla ノススメ」 | NTTデータ先端技術株式会社
  • 第5回「 SysRq ノススメ」 | NTTデータ先端技術株式会社

    Tweet 今回は、システムがデッドロックしたり無応答状態に陥ったりした場合に、システムの状態を取得するための Magic SysRq について紹介します。 Magic SysRq (以降 SysRq と略します)は他の手段での情報取得ができない状況でも使える有用な機能ですが、実際に活用するための難易度が高い情報取得方法ですので、事前に練習しておくことを推奨します。 SysRq を実行する上での注意点としては、以下の点が挙げられます。 取得するタイミング 出力されるログの量 割り込み禁止状態の影響 (1) 取得するタイミング SysRq は、問題事象が発生している間に取得する必要があります。問題事象の解消後に取得しても、有用な情報は得られません。これは、 SysRq を使うためには、問題事象が発生している間に SysRq 要求を発行できるように備えておくことが必要であることを意味しています

    第5回「 SysRq ノススメ」 | NTTデータ先端技術株式会社
  • 第4回「 udplogger ノススメ」 | NTTデータ先端技術株式会社

    Tweet 第3回では、シリアルコンソールを使えない場合の代替案である netconsole について紹介しました。今回は、 udplogger について紹介します。 udplogger は netconsole が送信したカーネルメッセージを受信するために作成されましたが、 syslog フォーマットに沿わないテキストメッセージを受信するためのプログラムとして利用することもできます。 bash は「 /dev/udp/IPアドレス/ポート番号」という構文を備えていますので、テキストメッセージを転送する用途で使用することができます。もし、 udplogger が待機しているIPアドレスが 192.168.0.1 でポート番号が 10000 の場合、以下のようにリダイレクト機能を用いて転送することが可能です。 $ while :; do date; sleep 1; done > /dev/

    第4回「 udplogger ノススメ」 | NTTデータ先端技術株式会社
  • 第3回「 netconsole ノススメ」 | NTTデータ先端技術株式会社

    Tweet 第2回では、カーネルパニックまで至らない場合の情報取得方法として、シリアルコンソールを紹介しました。今回は、シリアルコンソールを使えない場合の代替案である netconsole について紹介します。 netconsole とは、カーネルが出力するメッセージを取得するための、比較的簡単な方法です。 信頼性という点ではシリアルコンソールの方が上であると考えられますが、 netconsole であれば、ホストへのログインが許可されていない仮想化環境のゲストや、シリアルコンソールの有効化/無効化のために再起動することが困難なサーバーでも使うことができます。また、ネットワークを介してログを送信するため、多数のサーバーのカーネルメッセージを1台で受信させたり、クラスタ構成の場合には相手方のサーバーを受信側に指定したりといった利用方法も可能です。 netconsole を使用する上での注意点

    第3回「 netconsole ノススメ」 | NTTデータ先端技術株式会社