5. IBM Cloud • Why The Future Of Software And Apps Is Serverless by Ken Fromm, VP of Business Development at Iron.io – – – – http://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/
cloudpackの考える「サーバーレスアーキテクチャ」とは 最近、エンタープライズIT業界で「サーバーレスアーキテクチャ」あるいは「サーバーレス」という言葉を耳にするようになりました。このサーバーレスとは、いったいどのような概念なのでしょうか。 サーバーレスの文脈で登場するサービスには、アマゾンの「Lambda」、グーグルの「Google Cloud Functions」、IBMの「OpenWhisk」、マイクロソフトの「Azure Functions」など様々なものがあり、定義が異なっていますので、ここではcloudpackの考える「AWSにおけるサーバーレス」の意味を解説します。 AWSにおけるサーバーレスとは、「Amazon S3、DynamoDB、Lambdaを活用することで、インスタンスベースの仮想サーバー(EC2、ElastiChache、Redshiftなど)を使わずにアプ
この記事は第1回ウェブシステムアーキテクチャ(WSA)研究会の予稿です。 cronのようなタイムスケジューラーにより、定期的に実行されるバッチ処理の課題を解決するアーキテクチャを最近考えている。 この記事では、単一のタイムスケジューラによるcronベースの手法に代えて、データに対してタイマーと処理を仕込むことでスケールさせやすい構造にできないか、という提案を試みる。 はじめに Webサービスにおいて、リクエストに対してHTMLのレスポンスを返却する以外のワークロードの多様化が進んでいる。 最近であれば、機械学習による時間周期による大規模なデータ処理が求められることも多い。 その他、月次の課金バッチ処理や、ランキングの定期更新など、一定の時間間隔で任意の処理を実行したいケースは多い。 このような定期的なデータ処理パターンは、SRE本[Bet17]の25.1節「パイプラインのデザインパターンの
一年前にFastContainer構想という記事を書いてから、主にアカデミアでFastContainerに関する研究をすすめたり、FastContainerに基いて実装されている「ロリポップ!マネージドクラウド」というロリポップ!の新しいプランのリリースに向けて取り組みを行ったりしておりました。 hb.matsumoto-r.jp そこで、ブログでも「FastContainer: 実行環境の変化に素早く適応できる 恒常性を持つシステムアーキテクチャ」についての構想からのアップデートをまとめておきたいと思います。 英文タイトルは、 A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes です。 はじめに 背景 目的 提案の概要 Serverlessアーキテクチャによる実装との違い Her
対象読者 2つの疎結合なシステム間を、メモリを大量に使っちゃうような大がかりな仕組みなしで、ほぼリアルタイムにデータロスなしに同期させたい、そういうアーキテクチャが欲しい方。 動機 Microservicesを疎結合に保ちつつ、バッチ処理やレポート機能でのクエリの高速化のため、データを同期させたいことがままあります。このあたりの話は、テキストの「5章 モノリスの分割」に載っています。 あるサービスから、データを定期的に吸い上げて、別のサービス、ツールに送るデータポンプという仕組みがあります。 イベント駆動でメッセージを関連サービスに送るイベントデータポンプや、バックアップツールを使って高速にデータ転送するバックアップデータポンプが紹介されていますが、結果整合性だけどなるべくリアルタイム(Near Real-Time)で同期させたいとなると、イベントデータポンプな仕組みしか選択肢にはならない
このような対話を通じて、レストランの検索に必要な情報をユーザから取得し、レストラン検索を行います。 今回、レストラン検索にはHotPepperグルメサーチAPIを利用させていただきました。ありがとうございます。 システムアーキテクチャ 対話システムは複数のモジュールから構成されています。今回は、各モジュールは独立に動作させず、前段階のモジュールの処理が終わった段階で駆動されるようにしています。 最終的なシステムアーキテクチャは以下の図のようになりました。 今回のアーキテクチャに沿って処理の流れを説明すると以下のようになります。 ユーザがテキストを入力すると、入力したテキストは言語理解部に入力されます。 言語理解部では入力されたテキストを解析して、対話行為と呼ばれる抽象的な意味表現に変換します。 言語理解部から出力された対話行為は、対話管理部に入力されます。対話管理部では入力された対話行為を
前回(「企画と開発が責任を押し付け合う会社の前途は暗い」http://jbpress.ismedia.jp/articles/-/51448)は、「にわとり」と「たまご」の話を例に挙げて、ビジネス(ニーズ)と製品開発(シーズ)の関係の変化を説明した。今回は、アジャイルの起源にいったんさかのぼり、そこから時間を追って現在のビジネス視点での解釈について書いていきたい。 開発者の視点に立っていた古典アジャイル アジャイル開発宣言は2001年に発表された。「アジャイル」という言葉が登場すると、それ以前からあった「スクラム」や「XP(Extreme Programming)」をはじめとする軽量開発手法を総称する新しい呼び名として、大きなムーブメントとなった(ただし、注目を集めたのはソフトウエア開発の文脈においてであり、ムーブメントはソフトウエア開発者のコミュニティ内に限られていた)。アジャイルは、ソ
2018年5月6日: Headless ChromeがStableになった後の現状に合わせた新しい記事を書きました。こちらもご参照ください。 先日PhantomJSのVitalyさんがメンテナーを引退するという話が話題になっていました。ヘッドレスなブラウザーを気軽に使う手段としてPhantomJSにはお世話になりました。今後はHeadless Chromeを使って欲しいとのことなので、試してみました。 Node.jsを使うサンプルは多く見つかりますが、諸事情でPythonを使いたかったので、ここではSelenium経由でHeadless Chromeを使います。 Headless Chromeとは Google Chrome 59から使えるようになる予定の、画面を表示せずに動作するモードです。自動テストやWebスクレイピングなどに役立ちます。 2017年4月28日現在、Mac版とLinux
個人的に押さえておいたほうがいいと思う情報や最近動向が気になっている情報をまとめました。 短時間調べた程度でザックリ書いてますので、掲載している情報に間違いなどありましたら、 ご指摘いただけると助かります。 現時点でWorking Draft,Editor's Draftの情報もありますし、ブラウザ側でほとんど実装されてないプロパティ(業務ではあまり使えない系)も積極的に載せていっているので、対応状況についてはCan I useやMDNで調べてください。 途中まで載せてたけど多すぎてあきらめた... #HTML ##Resource Hints(dns-prefetch, preconnect, prefetch, prerender) 指定しておくことで、ページ遷移時に名前解決・接続・リソースの取得・レンダリングを早めることができる。 Link types - HTML | MDN ##
タイトル通りによく使う正規表現を毎回ググるのが効率悪いのでまとめてみました。各言語で正規表現のサンプルを書いてみました。 正規表現式 Emailアドレス ^\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$ ドメイン名 ^[a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]\.[a-zA-Z]{2,}$ インタネットURL ^(http|https)://([\w-]+\.)+[\w-]+(/[\w-./?%&=]*)?$ ユーザー名 (Twitter username) ^[a-zA-Z0-9_\-.]{3,15}$ 固定電話 ^0\d-\d{4}-\d{4}$ 携帯電話 ^(070|080|090)-\d{4}-\d{4}$ IP電話 ^050-\d{4}-\d{4}$ フリーダイヤル ^0120-\d{3}-\d{3}
Amazon Web Services ブログ AWS CodePipelineとAmazon ECSを使って継続的デリバリパイプラインを設定する この記事はAWS Senior Technical EvangelistのAbby Fullerの投稿です。 2017年12月12日に、AWSはAWS CodePipelineのターゲットとしてAmazon Elastic Container Service (ECS)をAWS Fargateも含めてサポートしたことをアナウンスしました。このサポートにより、コンテナベースのアプリケーションやマイクロサービスを継続的デリバリするパイプラインを作成するのがより簡単になりました。 コンテナ化したサービスを手動で構築しデプロイするのは、時間がかかりますしエラーを起こしがちです。自動化されたビルドとテスト機構と組み合わせた継続的デリバリは、早期にエラーを
こんにちは、 UXデザイナーの @yuh_iw です。 この記事は NTTコミュニケーションズ Advent Calendar 2017 の23日目です。 すべては最高の体験のために 弊社では、ようやく社内にUXデザインという言葉が浸透し始めていますが、 実態はUIと共に語られることが多いです。(実際は違うよ) とはいえ今回はUIを作るために私達がいつも行っていることについて記載します。 どうやってUIを作っていくのがよいか とにもかくにも、ユーザーに対する検証と学習をくり返すことです。 最高のUI=カッコイイUIではありません。アーティスティックなUIでもありません。 UIにはユーザーがいるので、ユーザーが使いやすいと思わなければならないのです。 そのために、使ってくれそうな人に、検証していく必要があります。 検証するためにはいくつか方法がありますが、 本稿ではUIプロトタイピングを行う
ヘッドレスChromeでシンプルに自動テストを行う Google Chromeのバージョン59から標準搭載された、ヘッドレスモード(GUIがないモード)。コマンドラインからヘッドレスブラウザを立ち上げることができ、スクリーンショットの撮影を行ったりDOMを出力したりすることができます。自動化の可能性に満ち溢れた機能です。 ヘッドレスChromeの導入については、次の公式ドキュメントが詳しいです。 ヘッドレス Chrome ことはじめ | Web | Google Developers ドキュメントを読んでいただくと分かると思いますが、様々なことが可能なため指示の記述が少し冗長な面があります。 そこでヘッドレスChromeを用いた自動化処理をシンプルにすることに特化した便利ツール「Chromeless」を紹介します。 なお、今回実装したソースコードはGitHubで公開しています。わせ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く