はじめに こんにちは、技術3課の紅林です。前回は、AWS Data PipelineでSlackの全チャンネルの1日分メッセージの取得を自動化する試みをご紹介しました。今回は、AWS Step Functions（以下、Step Functions）を使って、同様のことをしてみたいと思います。 AWS Step Functionsについて まず、Step Functionsの概要を公式サイトから引用します。 AWS Step Functions により、視覚的なワークフローを使用して、分散アプリケーション

6月29日、Enterprise APIs Hack-Night #10が開催されました。このコミュニティは企業におけるAPI活用を啓蒙、ナレッジをシェアしていくというものです。今回は原点回帰し、Enterprise APIがテーマとなっています。 こちらはそのレポート記事になります。 富士通による社内API化の取組み by 富士通株式会社　鈴木 弘樹さま 富士通ではプライベートクラウドの中でApigeeを採用しています。そしてクラウドサービスとしてAPIマネージメントを提供し、お客様含めてエコシステムを

企業間におけるAPI利用が拡大していくと、API自体が利益を生み出すAPIエコノミーが広がっていきます。 APIエコノミー自体については以前記事にしています が、その中で考えるべき視点がサービスのAPI化です。 より複雑な処理をRESTfulで処理する 単純なデータベース構造やモデルの公開はRESTfulによって処理を行えます。RESTfulは開発者にとって分かりやすく、使い勝手の良いAPIフォーマットになりますが、幾つかの問題点があります。その一つがクライアント側（利用側）のコード量が増大することです。

マイクロサービス システムをごく小さくまとめ、APIベースで機能を提供するマイクロサービスがより広がっていくと考えられます。多くのモノリシックなシステムにおいて密結合が拡張性やメンテナンス性において負の資産となっています。マイクロサービス化することで結合ポイントを減らし、開発を容易にします。 マイクロサービスは多くがモデルデータのCRUD操作をREST APIにて提供します。HTMLを返すものは多くありません。まさにAPI向けの施策と言えるでしょう。ただし、サービスの分け方をうまくやらないと、ただシステム

昨今人気を集めているGo言語ですが、メリットとして以下の点が挙げられます。 ビルド後の実行速度が速い 環境構築のスピードが速い バージョン依存の問題が少ない 環境依存の問題が少ない ポータル性がよい 逆にデメリットとしては以下の点も良く挙げられます。 JSON、XMLなどの扱いにも厳密な構造体が必要になる 冗長的になりがちな戻り値のエラーチェック デバッガや、Loggerなどが充実していない 開発時・運用時のノウハウ・ナレッジが、まだまだ少ない そんな中、上記のデメリットをカバーするためにGoによるマイク

これから新機能をマイクロサービスとして作る場合、どういった用途であれば向いている言えるでしょうか。向き不向きを正しく把握できれば、開発しやすく、かつメンテナンスしやすいシステムが作れるはずです。 1アクセスが1秒以下 サーバレスアーキテクチャは長時間のアクセスが求められるような仕組みは不向きです。そのため、データベースもRDBMSよりNoSQLであったりKVSのものが向いていると言えます。一瞬のアクセスで結果を受け取って返す、といったものが向いています。 長時間の処理が必要なものは現状のサーバ環境を使った

ここ1、2年くらいで注目が集まっているのがマイクロサービスと言われるシステムアーキテクチャです。今回はそんなマイクロサービスの特徴を紹介します。 小さくシステムを定義して組み合わせる マイクロサービスはその名の通り、小さな（マイクロ）サービスに特化したアーキテクチャです。例えば認証/ユーザ管理や決済など特定の機能に特化した部分を一まとめにして構築します。バックグラウンドのデータベースについては共通化されていたり、クラスタリングを組んで参照については個々のマイクロサービスでデータベースを持っている場合もあり

マイクロサービスとは マイクロサービスとは、単一のアプリケーションを小さなサービス群の組み合わせとして構築する手法です。それぞれのサービス同士は疎結合とし、RESTful APIなどで接続をおこないます。そのアーキテクチャを支えるため、各言語でマイクロサービスフレームワークが存在します。今回は、言語ごとに主なソフトウェアをピックアップして紹介します。 PHP Lumen LaravelがベースとなるPHPのマイクロフレームワークです。ベンチマークではPHP系マイクロフレームワークで最速としています。またL

9月27日、サンフランシスコにてAdapt or Dieが開催されました。昨年は、I Love APIで3日コースでしたが、今年は1日に圧縮で、5都市で実施とのこと。先日、Googleが買収を発表したApigee主催のイベントでいろいろ興味深いところです。こちらはそのレポートになります。その1に続いて、クラウドとマイクロサービスセッションをレポート。 Adapt or Die Microservices with Node.js and Docker： 登壇者：Tony Pujals - Director

こんにちは。技術基盤部の磯野です。 ちょっと間が空いてしまいましたが引き続きZipkinです。 今回は Ruby + Sinatra で動いている Webアプリケーションへのトレーサーの導入です。 前々回の記事 → Zipkinを導入してみた（サーバー編） 前回の記事 → Zipkinを導入してみた（PHP編） 構成 CompositeAPIでの処理の流れ RestAPIでの処理の流れ 処理の流れを追跡するためのリクエストヘッダ app.rbの設定 (CompositeAPI, RestAPI共通) mo

こんにちは。技術基盤部の磯野です。 弊社ではここ数年、HOME'Sのクラウド化やマイクロサービス化を推進しています。 アプリケーションのクラウドサービスへの移行に関してはそろそろ終わりが見えてきているのですが、 マイクロサービスに関してはまだまだ道半ばということもあり、推進していくにあたって、 各サービス間の依存関係やトレース情報を可視化する手段としてzipkinをAWS上に試験的に導入してみました。 今回はZipkinサーバーの導入までの手順についてまとめたいと思います。 Zipkin とは データスト

こんにちは、技術１課多田です。 先週は、AWS Summit Tokyo 2016が開催され、会場では身動きを取るのがやっとなくらい、たくさんの方がいらしておりました！ これがAWSの勢いを表しているものだと実感した次第です。 AWS Summitの模様については、下記のブログにも詳しく載っておりますのでご覧ください。 [AWS Summit Tokyo 2016セッションレポート]クラウドとマイクロサービスによる音声操作の新時代 － Amazon Echo & Alexa 【AWS Summit Tok

こんにちは。CS課の坂本（@t_sakam）です。 現在絶賛開催中の「AWS Summit Tokyo」、会場からのセッションレポートです！ 今回は「グランドプリンスホテル新高輪」の「飛天（ひてん）」でおこなわれている、「Developers Conference」の会場にやってきましたー！Developers Conference日時6/2（木） 14:20 ～ 15:00場所グランドプリンスホテル新高輪「飛天」セッションタイトルサーバーレスで構築する、マイクロサービスの未来形スピーカーTim Wagn

こんにちは。大阪オフィスの桶谷です。 午前中に大阪から東京に移動し、AWS Summit Tokyo 2016に来ています。 元々6/3(金)だけの参加予定だったのですが、6/2(木)のDevConのKeynoteがEcho & Alexaに決まったため、予定を変更して1日前倒ししました。 ということでAWS Summit Tokyo 2016 Developers Conferenceの「クラウドとマイクロサービスによる音声操作の新時代 － Amazon Echo & Alexa」をレポートしたいと思い

こんにちは、VASILYのバックエンドエンジニアの塩崎です。 iQONの中ではクローラーと検索サーバーを担当しています。 iQONのクローラーには提携ECサイトさんからクロールした商品を商品カテゴリー(Tシャツ、ワンピース、etc.)に自動的に分類する機能があり、商品タイトルや商品説明文などのテキスト情報を元に分類を行っています。 しかし、一部のカテゴリー(セーター・ニット帽)の商品はテキスト情報だけからでは精度の良い分類を行うことができません。 そのため、これらのカテゴリーの商品については画像を用いたカ