マルチコア時代のプログラマは関数脳になろう〜Scala・Clojure〜 - Tech-Sketch
前回 の記事では、関数型プログラミングの概念とJava8による実装例を示しました。しかしJava8のリリースは来年まで延期されてしまったため、今すぐ試してみるには少しハードルが高いかもしれません。 そこで今回は、Java7のJVM上で動作する代表的な関数型プログラミング言語、 Scala と Clojure を紹介します。 Scalaとは では、 Scala から紹介しましょう。 ScalaはJVM上で動作するプログラミング言語で、関数型の特徴とオブジェクト指向の特徴を合わせ持った、欲張りな言語です。 JVM上で動作するため、既存の膨大なJavaライブラリをそのまま流用でき、JVMのパフォーマンスチューニングノウハウを最大限活用することができます。またJavaよりも豊富な記述形式を持ちながらもJavaオブジェクトをそのまま扱え、強力な型推論を持った静的型付け言語でもあるため、定型的で冗
マルチコア時代のプログラマは関数脳になろう〜Java8のススメ〜 - Tech-Sketch
CPUのクロックアップに限界が訪れ、マルチコア化することで処理性能向上を目指す時代になりました。これからのプログラマには、マルチコアで処理性能が向上するプログラム＝マルチスレッドで並列処理が可能なプログラムを書く能力が必要になります。今回は「関数型」でプログラムを書くことによって、いとも簡単に並列化ができることを実例を元に解説します。 関数型プログラミングと並列処理 「関数型でプログラムを書くことで簡単に並列化できる」と書きましたが、そもそもここで言う「関数」とは何なのでしょうか？ 関数型プログラミングの特徴 関数型プログラミングの「関数」を理解するためには、数学における「関数」を想像するとわかりやすいでしょう。 例えば三角関数を用いた y=cos(x) という式を考えてみます。この式に入力値 x=0 を与えた場合、いつでも必ず結果は y=1 になります。x= π/3 の場合は y =
AWS OpsWorksを使ってみた (技術編) - Tech-Sketch
AWS OpsWorksを使ってみた（概要編） では、AWS OpsWorksの概要について紹介しました。今回の記事ではそれに補足して、前回触れられなかったOpsWorksの機能の詳細や、OpsWorksの初期構築処理の仕組みに関して把握できた範囲で紹介します。 OpsWorksの各種機能 前回の記事 でも特徴の所で簡単に触れましたが、OpsWorksにはChefによる自動構築以外にも様々な機能が用意されています。まずは前回掘り下げられなかったこれらの機能について、簡単に紹介していきます。 Auto Healing (障害自動復旧) Auto Healingは、インスタンスの障害を検知した際に代替となる新しいインスタンスを自動的に立ち上げる機能です。OpsWorksの各インスタンスではOpsWorks Agentと呼ばれるサービスが稼動しており、定期的にKeepaliveパケットを送信して
AWS OpsWorksを使ってみた (概要編) - Tech-Sketch
今回は2013年2月にβ版が公開されたAWSの新たなアプリケーション管理サービスであるAWS OpsWorksについて、その概要を紹介します。 AWS OpsWorksとは AWS OpsWorks(以下OpsWorks)とは、環境構築とアプリケーションのデプロイの自動化・統合管理を実現するサービスです。OpsWorksを用いることで、柔軟に構成変更が可能な環境一式をAWS内に自動構築することができ、アプリケーションのデプロイもコンソールから指示するだけで自動的に行うことが出来ます。 AWSは以前からアプリケーション管理サービスに分類しているサービスをいくつか提供しています。AWS Elastic Beanstalkでは、アプリケーションを動かす環境一式を選択肢から選ぶだけで環境が自動構築され、アプリケーションコードだけを用意すればすぐにWebサービスを稼動させることができます。AWS C
Fluentdの仕組み -バッファ機能でログ収集漏れを防ぐ- - Tech-Sketch
OSSのログ収集管理ツールFluentdを用いてログを統合管理している場合の懸念点として、ログの収集漏れが考えられます。 Fluentdでは、バッファ機能を活用することでログを収集漏れすることなく確実に収集することができます。 このバッファ機能のメカニズムを理解すべく動作検証した結果を紹介します。対象とするFluentdのバージョンは0.10.30です。 Fluentdとは Ruby実装のOSSのログ収集管理ツールです。 Fluentdは、Input、Buffer、Outputの3つのコンポーネントで実現されています。 様々な場所からログを収集、JSON形式に変換し(Input)、蓄積(Buffer)、様々な出力先にデータ出力(Output)します。 例として、あるサーバ(server01)のApacheのアクセスログを別のサーバ(server02)内にファイルとして出力する場合
Hadoop Pig の使いどころ - Tech-Sketch
「PigとHive何が違うの？」 「Difference between Pig and Hive? Why have both?(PigとHive何が違うの？)」 という質問を、先日、StackOverFlowで見かけました。恐らくHadoopを触ると一度は疑問に思う事ではではないでしょうか。 PigとHiveは、共にSQLライクな記法でMapReduceを書けるDSLですが、利用者数においてはHiveに軍配が上がっているようにみえます。 一方で、「Pigをもっと早く試せば良かった」というお話を伺うこともあり、有用（かもしれない）ツールであれば、正しく理解しておいた方がよさそうです。 というわけで、ここではPigの活用を探ります。 Pigの性能 Pigが今一つ利用されていないのは、SQLとの親和性に加え、性能面で、「JavaMapReduce＞Hive＞Pig」という傾向があるからで
システム間連携 その４：ZeroMQ - Tech-Sketch
1.はじめに ３回にわたり、システム間連携を行う際の高付加価値な機能としてMOM(Message Oriented Middleware)のRabbitMQ,ESB(Enterprise Service Bus)のJBossESB,Muleを紹介してきました。今回は視点を変え、すべての通信の基礎となるソケット通信(以下、Berkeley socketsと呼びます)のAPIに焦点をあて、それに対するフレームワークであるZeroMQ(http://www.zeromq.org/)を紹介します。 2.Berkeley socketsの問題点 Berkeley socketsを用いたシステム間連携(TCP/IP通信)の処理の流れは次のようになります。 このソケット通信はMOMを用いたシステム間連携と対比しますと付加価値機能が無い分だけ高速に動作し、ハブ＆スポークのハブにあたる部分が無いためシステ
リアルタイム分散処理Stormの耐障害性は？ - Tech-Sketch
リアルタイム分散処理とは 「ビッグデータ」処理のためにHadoopを用いますと、「複数のマシンに大量データ処理を分散して飛躍的に性能を向上する」ことが容易に可能となります。 ところがHadoopの弱点としまして、ビッグデータをいったん蓄積し、バッチで一括処理する形態で処理が行われますので、処理データが発生してからそれに対する処理結果が得られるまで必ずタイムラグが発生します。このため、クレジットカードの不正アクセス検知、センサーデータなどでの異常値検出のようなリアルタイムなレスポンス(低レイテンシー)が要求されるビッグデータ分野へのHadoopの適用は向いておりません。 このような随時発生する大量データ（ストリーミングデータ）を、蓄積せずにリアルタイムに処理する「リアルタイム分散処理」が求められています。 今回は、リアルタイム分散処理のソリューションとしてTwitter社より公開された
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
