Amazon Web Services ブログ

Category: General

LiveOps Cloud – AWS を使用した数十億ドル規模のコールセンター市場の開発

LiveOps Cloud は広大な未開発市場を開こうとしています。LiveOps Cloud は、コンタクトセンター業界におけるソリューションプロバイダとして長年サービスを提供してきました。最近では、完全に AWS を使用して構築され、運用されている、CxEngage という新しい Contact Center-as-a-service プラットフォームを立ち上げました。LiveOps Cloud のエンジニアリング CTO 兼 SVP、Jeff Thompson 氏にこのすばらしい最新のサービスを開始するに至った経緯について尋ねてみました。 – Jeff; LiveOps Cloud は創立 16 年の企業です。当社は LiveOps Inc から生まれた新しい企業で、母体会社のコンタクトセンターソリューション提供における長い歴史を、クラウドの利便性、パフォーマンス、低コストが重視される新しい時代へと引き継いでいくことが我々のミッションです。 コンタクトセンタービジネスは広大で、世界中に少なく見積もっても 1,500 万人もの雇用を生み出す、数十億ドル規模からなる市場です。しかしながら、この業界はクラウドコンピューティングとしては後発で、クラウドインフラストラクチャとツールに関する技能を持つのは、コンタクトセンター就労人口のわずか 10% 程度です。特に銀行や小売業などの伝統的業種では、有効期限が近づいているオンプレミスのレガシーコールセンターシステムが多数存在しています。これらのシステムは、コスト削減、パフォーマンスの向上と高度化、新興市場への対応といった、企業が抱える現在の市場ニーズを満たすには不適当です。 クラウドベークオフ 当社では、100% クラウドで稼働する contact center-as-a-service (CCaaS) を作成を計画していました。システムは常時稼働し、安全で、マルチテナントで、すぐにスケーリングできるプラットフォームなので、いつでもどこでもお客様に特化したサービスを提供できます。当社の CCaaS はまさに "ホッケースティック" のような高成長パターンを遂げることを期待しています。それを実現するために、どんなプラットフォームが最も効果的かを注意深く考慮する必要がありました。 ベークオフ前に、いくつかの代替案を探しました。Azure、Rackspace、Google、および AWS はクラウド内のプロバイダミックスに入っており、コロケーション設備の使用を考えました。しかし、最後にあげたサービスこそ、まず向かうべきところでした。コロケーション外で運用するプラットフォームでは、新しいプラットフォームに組み込む必要のある、冗長化とスケーラビリティを実現できないことを経験を通して知っていました。当社は Microsoft 販売店ではなく、プラットフォームの作成に Windows 以外の多くのツールと Linux を多く使用するため、Azure は除外しました。Rackspace の […]

Read More

より良いがん治療を目指して – Fred Hutchinson がん研究センターとの共同作業

Jessica Beegle 氏と Christopher Crosbie 氏による刺激を与える経験談。 – Jeff; がん研究の科学は、新たな学術分野を取り込みながら進化を続けています。例えば、化学療法、増幅放射線治療、および発がん性物質特定のための疫学分野の進歩がこれに含まれます。また病理学によって、病気の様々な症状に対する理解が深まってきています。 コンピュータサイエンスの原則は、がんについての理解と治療方法の探求において、比較的新しい切り口となっています。コンピュータサイエンスに求められているのは、特定の DNA の差異が、がんとどのように関連しているかを解読し、それぞれの患者に対してどのような治療法が最も効果的かを解明することです。ゲノミクスと呼ばれる DNA 研究には、非常に巨大なデータ処理能力が求められるため、この種のタスクを処理するにはコンピュータサイエンスが最適でしょう。実際、科学者たちは、ゲノミクスによって 2025 年までに天文学、YouTube、Twitter を上回るデジタル情報が生成されることを予言しています。 現在はこのようなデータの収集、分析、視覚化のために開発されるソフトウェアの多くが、異なる IT システム、研究施設、ヘルスケア機関、および政府機関といった組織の中で生み出されています。これらの隔たりによって、科学上の発見のスピードが著しく阻害されています。 シアトルにある Fred Hutchinson がん研究センターの研究者たちは、この状況を変えようとしてきました。Fred Hutchinson がん研究センターのヒト生物学部門、および固形腫瘍トランスレーショナルリサーチの理事 Eric Holland 医学博士が率いる研究チームは、分子および医療データの分析ツールの使用と開発を目的とした、Oncoscape と呼ばれるオープンソースウェブアプリケーションを開発しました。Oncoscape により、研究者たちは新たなパターンや関連性を発見できるようになり、さらなるがん研究の発展が可能になりました。 コンピュータサイエンスの現在の技術を活用するため、Oncoscape チームは Github および AWS を採用しました。それにより、Github が提供するコード共有プラットフォームと、AWS が提供するクラウドコンピューティング機能を組み合わせ、相乗効果をもたらすことが期待されました。Holland 博士は次のように語っています。 Oncoscape をクラウドにホスティングすることにより、ソフトウェアの変更および再デプロイが容易になり、開発チームは研究コミュニティのニーズにすばやく対応できます。世界のどこからでもサイトに安全にアクセスできることを知っているので、データのビジュアル化で何が可能になるか、がん研究で協働するためどのように共通のプラットフォームを活用できるかを共同研究者たちに示すことができます。 Oncoscape の AWS デプロイを支援した IT ソリューションアーキテクトの Robert McDermott 氏は、「AWS はプロジェクトのニーズにすばやく対応する上で非常に有能で信頼でき、柔軟性に富むプラットフォームだ」と述べています。さらに、成熟度、信頼性、サービスの幅広さ、およびセキュリティが、AWS を使用する強力な理由となったと述べています。 Oncoscape は […]

Read More

ヒッグス粒子を発見した実験で自然界の調査に AWS を使用

同僚の Sanjay Padhi は AWS サイエンティフィックコンピューティングチームの一員です。Sanjay は、重要な科学的発見に役立つコンピューティングリソースを AWS がどのように提供したかに関するゲスト投稿を行いました。 – Jeff 質量の起源への洞察を提供する上で重要な役割を担うヒッグス粒子 (神の粒子と呼ばれることもある) は、2012 年に、スイスのジュネーブにある CERN の大型ハドロン衝突型加速器 (LHC) で、世界最大の実験装置である ATLAS および CMS により発見されました。この発見の基盤となる理論を提唱した研究者たちは、2013 年ノーベル物理学賞を受賞しています。 フランスとスイスの国境にまたがって地下深くに設置されている LHC は、世界最大 (全周 17 マイル) でこれまでにない高エネルギーの粒子加速器です。これにより、これまで探求してきたいかなる人間の発明よりも小さいスケールで自然界を探ることができます。 実験から生データへ 高エネルギー粒子の衝突により、質量はエネルギーに変換され、その後質量に再変換されて、新しい粒子が作り出されます。この粒子が CMS 検出器で観察されます。この検出器は長さ 69 フィート、幅 49 フィート、高さ 49 フィートで、フランスのセシー村近くにある地下 328 フィートのトンネルに設置されています。CMS からの生データは 1 秒あたり約 1 ペタバイトの割合で 25 ナノ秒毎に記録されます。 CERN Tier 0 データセンターで生データをオンラインおよびオフライン処理した後、そのデータセットは 48 […]

Read More

Airbnb – AWS で宿泊業界の新しいスタイルをつくる

Airbnb は、わずか数人のすばらしい着想が業界全体を大きく変えることがあることを示す、典型的なストーリーです。2008 年にスタートして以来、これまでに 8000 万人の客が Airbnb を利用して 190 以上の国にある 200 万軒以上の家に宿泊しました。最近では、全世界からの旅行者のため、キューバに 4000 軒の家をオープンしました。同社はまた、早くから AWS を活用してきました。 ゲストによる以下の投稿の中では、Airbnb エンジニアリングマネージャーである Kevin Rice 氏が、スタートアップにおいて AWS がどれほど重要な役割を担ったか、そしてどのようにその重要な位置にとどまっているかを解説しています。 – Jeff PS – スタートアップが AWS を利用してビジネスを展開する方法の詳細についてもご覧ください。 初期 当社の創設者たちは、Airbnb を成功させるために、スピーディーかつリーンであることが必要だと認識していました。これには、インフラストラクチャに投じる時間とリソースを最小化することが不可欠です。当社のチームは、ベーシックなホスティングについての業務にではなく、ビジネスを離陸させることに集中することが必要でした。 幸いなことに、ちょうどそのとき、アマゾン ウェブ サービスにはコンピューティングとストレージにおいて非常に成熟したサービスが構築されていたため、当社のスタッフは他の人からのサポートや最小使用要件に気を使うことなく、サーバーを立ち上げることができました。同社のクラウドコンピューティング機能のほぼすべてを AWS に移行することが決定されました。スタート当初の小さな企業では、利用できるリソースを可能な限り活用する必要があります。当社の従業員たちは、ビジネスを成功させるために替えのきかないところに注意を集中したいと考えていました。 Airbnb では、Amazon EC2 や Amazon S3 といった AWS の基本サービスの多くをすばやく導入しました。当初の MySQL データベースは Amazon Relational Database Service (Amazon RDS) に移行されました。RDS […]

Read More

10 Lessons from 10 Years of Amazon Web Services ~ AWS10年に学ぶ10のレッスン

  Amazon.comのCTO  Werner Vogelsが、彼のブログでこの10年のAWSの軌跡を振り返っています。ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。 ——————– AWSの革新は2006年3月14日のAmazon S3のローンチで、約10年前の出来事でした。10年前を振り返ると、低価格で予測可能なパフォーマンスにより、セキュアで、信頼性があり、拡張性が高い、構築・運用が実現できていることから、数百もの学びがあります。AWSは、世界規模でサービスを構築・運用できるパイオニアであり、これらの学びは我々のビジネスにとってとても重要です。以前も何度となくお伝えしている通り、経験だけはショートカットするする方法がない、ということです。毎月の数百万ものアクティブなお客様と共に、彼らの先にいる数億ものお客様と共に、お客様にサービスを提供しながら改善するためのまたとない環境と学ぶ機会を得ています。 みなさんと共有したいいくつかの学びをご紹介します。 1. 進化可能な仕組みを構築する ビジネスが始まる初日から、開発していたソフトウェアは、もはやソフトウェアに非ず、ということを一年間走らせてみてわかりました。その期待値は、金額でいえば一桁、二桁も異なり、スケールの問題を解決する為のアーキテクチャの再考が必要になったものです。   とはいえ、世界中で24時間365日多くのシステムが我々のプラットホームで動作しているのですが、システムアップグレード時にメンテナンスによる中断を起こさないようにする形態をとることはできませんでした。我々は、サービス停止を起こさずに新たなコンポーネントを導入できるアーキテクチャを作る必要がありました。Marvin Theimer, Amazon Distinguished Engineerの彼が、Amazon S3を例えば言うならば、当初は単機エンジンだったセスナが、時間を経過するとボーイング737や747sにアップグレードされている、そして最後はエアバス380sのようだ、と冗談まがいに言っていました。成長の途中で、空中燃料補給をしながら、お客様に築かれないように飛行機を乗り換えているようだと。   2. 想定していないことを想定する 失敗はもたらされるもので、すべてが最後は失敗に成り立っている。ルーターからハードディスク、OSからメモリユニット、誤ったTCPパケット、一時的なエラーから、永続的な故障などがあります。これは、最高品質のハードウェアであろうが量産品であろうが、最終的な顛末は同じです。 拡張性において、さらに重要になってきます。例えば、S3が数兆回ものトランザクションを処理しているときでも、ほんのわずかな可能性でも、それは現実に起こります。このような故障のシナリオの多くは事前に予知できますが、設計や構築時点では知る由もありません。 我々は、故障が何なのかは知らずとも、自然発生で起こる故障も冗長化しカバーできる構築が必要でした。システムがもし火事にあったとしても動作し続ける構造が必要なのです。システム全体をダウンさせることなく、個々のモジュールを管理できることが重要です。我々は、システム全体のヘルスチェックを可能にするような、故障発生時の影響範囲を管理する基本的な仕組みを開発しました。   3. フレームワークでなくプリミティブ ほどなくして、AWSのサービスを利用したいと考えている企業の多くは既に何らかのAWSサービスを取り組んでいると気づきました。お客様が制約を許容し、過去のIT関連のハードウェアとデータセンターの世界と決別すると、前例のない使用パターンで構築し始めるということが起こりました。そのように、お客様のニーズに合ったものを確実に届ける為に、素早く動かざるを得ない状況でした。 もっとも重要な事のひとつに、小さなサービスやツールをお客様に届けるという事で、ひとつのフレームワークを強制されるよりも、キッチンの道具のようにすべてそろっていて組み合わせるように、AWSクラウドで実現できる最適な方法を選んでいただけるような構成にしていました。この方法はお客様の成功につながりましたし、後にAWSのサービスの基本的な製品/サービスの考え方をして活用しています。 お客様がサービスを手に取り、使って構築するまで、どのような優先順位で対応すべきか予期することは難しい、ということに気付くのが重要です。最小の機能性でサービスをリリースし、お客様の要望に合わせてサービスのロードマップを作っています。 4. 自動化がカギ サービスを構築するのと従来のソフトウェア開発でお客様に納品するのとは大きく異なります。拡張性の高いシステムを管理するには、お客様の期待する信頼性、パフォーマンス、スケーラビリティに合うようにする異なるマインドセットが必要です。できるだけ自動化を可能にし、マニュアル操作とエラーを事前に取り除く管理方法を実現するには自動化が重要なカギになります。実現するには、操作に重要となる機能を制御するAPIを構築する必要がありました。お客様にも同様に助けになることです。アプリケーションの構造を分解し、それぞれ管理用APIで、拡張可能でパフォーマンスとメンテナンス性に優れたルールを作ることができます。 5. APIは永続 アマゾンの小売りの経験から得たものでもありますが、AWSがAPI中心のビジネスになることはさらに重要です。お客様が我々のAPIを使ったシステムとアプリを構築し始めたのなら、お客様のビジネスに影響を与えるとして、APIを変更することは不可能になります。APIのデザインは非常に重要であり、正しく設計できるチャンスは一度きりだということを肝に銘じねばなりません。 6. リソースの使い方を知る 適切なサービス利用料を特定しサービスを見積もる際には、コストと運用の良いデータを手に入れることです。特に薄利多売のビジネスモデルにおいてです。AWSはコストを低減させるための努力を惜しまないため、お客様に届けるサービスも投資してもよいと思えるものであり、さらに値下げしても運用継続可能な範囲を見極め、利益を低価格という形でお客様に還元しています。 先の一例として、S3ではどの程度使用されるかパターンがわかりませんでした。ですから、ストレージとネットワークの帯域に対して主な課金を行うというように仮定しました。しばらく運用した後、リクエスト回数も同様に重要な指標だと気づきました。もしお客様がたくさんの小さなファイルを持っているとすると、ストレージと帯域は何百万件のリクエストであろうと計算しませんでした。我々は、AWSのビジネスが継続的なものになるよう、計算モデルを調整しなければなりませんでした。 7. ゼロからのセキュリティ対策 お客様をセキュリティの脅威から守ることは、運用の観点においても、提供するツールや仕組みにおいても、AWSとしては最優先すべき事項です。我々が永遠に投資をし続ける領域です。 素早く学ぶひとつのアプローチとして、最初にサービスを企画・設計する段階で、セキュリティ対策を組み込んでおくことが必須です。セキュリティの専門チームは、何かを構築してから検証するチームではありません。サービスが始まるその日からパートナーとして基本的なセキュリティが担保され強固であるか確認しています。セキュリティに関しては妥協しません。 8. 暗号化は最良の住人 暗号化はお客様にとってデータにアクセスする人に対する最大の制御方法であると言えます。10年前、暗号化のツールやサービスは使いにくく、我々のサービスにどう組み込むのがベストか検討しました。 暗号化はコンプライアンス順守の観点で、サーバーサイドの暗号化をS3で実装しました。もしあなたがデータセンターでディスクをのぞき見しようとしても、どのデータへもアクセスはできないでしょう。しかし、Amazon CloudHSMと後のAmazon Key Management Serviceを使えば、お客様は独自キーの管理とそれを使った暗号化ができるようになります。 今では、暗号化対応は新サービスには企画・設計段階で統合されています。例えば、Amazon Redshiftは、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。 暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。 […]

Read More

Ten Years in the AWS Cloud – How Time Flies! ~ AWSクラウドの10年

  10年前の今日、simple blog postでAmazon S3のローンチについて発表しました!それから10年経過したとは信じ難いです。そうでなければ、2000ものブログ記事を書いてはいないでしょう。   Future Shock私が高校生の頃、1977年当時新しいと言われていたFuture Shockというタイトルの書籍を読んでレポートを書きました。その本の中で、未来学者のAlvin Tofflerが急速な変化は、人々を圧倒し、ストレスを加え、方向を失わせることについて論じていました。そのレポートをごみ箱に捨てるまでの間、変化はよいことであり、人も組織も受け入れ対処することによってさらによくなる、と議論したのを覚えています。 まだキャリアの浅い頃、多くの予見されている技術は、新しいものに移行するというよりも、過去のものをよりよくしている状況でした。その時、私は21歳で、過去よりも未来の技術の世界でやっていく、変化と進化を受け入れるだけではなく、積極的に探し求める、と決めました。その決断から35年が経ちました。2004年に最初のブログを書き始め、今では10年もの間AWSに関連するニュースをお届けすることができています。 A Decade of IT Change ~ 10年の軌跡、ITの変化10年10年を振り返ってみると、ITの世界がどれだけ変化したのかを目の当たりにし、とても感銘を受けます。さらに印象深いことは、技術の面だけに留まらず、ビジネスモデルやその関連する事も変化しました。そのビジネス面の変化は、手に入れる、消費する、資源に対して支払う方法に新たな手段をもたらしました。エンタープライズやスタートアップの両方で起こっています。我々の使う表現や描写までも変化しているのです!10年前、まさか「クラウド」「マイクロサービス」「サーバレスアプリ」「IoT(モノのインターネット)」「コンテナサービス」「リーンスタートアップ」などという言葉を口にするとは思いませんでした。加えて「継続的インテグレーション」「継続的デリバリ」「DevOps」「ChatOps」を行っているとも思いませんでした。ChatOpsを試したことがないのであれば、VoiceOpsなるさらに新しい技術もあるのでお忘れなく。 むろん、変化をつかまえることは簡単な事ではありません。将来を見たとき、一瞬で終わるものなのか、それとも本物のトレンドなのかを見極めるようになることが必要で、昨日あったたわいもない技術が明日には本流になる技術に、すぐに軸足を変えられる柔軟さも持ち合わせていなければなりません。JavaScriptをその例として用います。(私のような)あなたが、もし、初期のころサーバサイドの開発者としてJaveScriptがあったら気にも留めなかったでしょうし、ブラウザのみで動作する言語は無視したでしょう、あなたは疑いもなくAjaxといった機能豊富で動的なアプリやNode.jsなどサーバ側で動く言語を動作させなかったでしょう。 今日、現状が意味するところは、同じプログラム言語、システムアーキテクチャ、業界のベストプラクティスが存在するということです。それは、現状のスキルを磨くことや新たなものを探すことに日々時間を使ったほうがいいということを意味しています。一日のうちに複数の開発が同時に起こる新しい世界が、グローバルチームと合意・協働し、ビジネス価値を提供し続けて、当たり前の状態になってきます。 A Decade of AWS ~ AWSの10年AWSがローンチしたいくつかのサービスとブログ記事を見てみましょう。 最初でいまだ関連の深いサービス (2006) – Amazon S3 とてもシンプルなコンセプトですが、裏側の仕組みは複雑に動作しています。TechCrunchが革新的だと当時言っていました! 時間単位のサーバリソース (2006) – Amazon EC2 Cabo San Lucanのプールサイドに座ってブログを書いていました。ローンチは数か月間ひっ迫し、飛行機に乗る直前で世に出ました。そのシンプルなスタート(インスタンスタイプはひとつ、ひとつのリージョン対応、CLIのみでアクセス)から、今ではお客様の声を多数取り入れ現在に至ります。2006年の今日の出来事でした。 データベースを簡単に (2009) – Amazon Relational Database Service (RDS) インストールに時間を使う、チューニングするなどMySQLの管理工数は高く、個人的にも長期的なプロジェクト課題でした。RDSがいかにワークロードを軽くしたか、感謝したいです。 高度なネットワーク (2009) – Amazon Virtual Private Cloud […]

Read More

A Decade of Innovation ~ イノベーション10年の軌跡

  AWSのVP and Distinguished EngineerであるJames Hamiltonが、彼のブログでこの10年のAWSの軌跡を振り返っています。ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。 ——————–   2006年3月14日はコンピューティングの新時代の始まりでした。それは、Amazon Web ServicesがSimple Storage Service (S3)をリリースした日だからです。技術の点では、Simple Queuing Services (SQS) が先にリリースされましたが、クラウドコンピューティングにおいては、S3が光を点したといえるでしょう。その日をよく覚えています。そのとき私は、Microsoftの子会社となったアンチスパム、アンチマルウェア、アーカイブサービスをクラウドで提供するFrontbridge Technologiesのジェネラルマネージャでした。この経験で、クラウド管理型サービスの顧客価値がわかりました。お客様も設定のスピードが速くコストが低減できるクラウドが好きなことがわかり、多くの経験から既に気持ちが変化していました。クラウドホスティングが今後の本流だと感じたものです。  いまだにS3の発表は私にとって開眼した出来事です。テクノロジ業界は毎日100もの発表をしていますが、多くを目にすることはありません。多くの場合、興味がわくようなものではないのです。でも、S3の発表は革新的でした。特に驚いたのはサービスの価格でした。我々が当時支払っていたデータセンターの冗長ストレージの2桁近く安い価格だったのです。でも、さらなる破壊的な事もあり、サービスを利用するにはクレジットカードのみ登録すればよいという事でした。経理の承認の裁可もいらないし、相見積を取る必要もなく、ベンダーを選ぶ必要もなく、ベンダーとの交渉も必要なく、データセンターのスペースを探す必要もありませんでした。ただ、サインアップして使い始めることができたのです。 注目すべきことは、低価格と設定の容易さで、いわゆるトラディショナルなエンタープライズのITプレイヤーではなく、あのAmazonから発表があったという事なのです。高い中間マージンが必要で、交渉が難しく、ライセンス使用の監査も必要な企業ではなく、あのAmazonなのです。多くの企業においては、中間マージンが得られなければ、経営層を変えろという話になるでしょう。Amazonのビジネスは大きな変化をもたらしました。異なるサプライヤ、異なるビジネスモデル、設定にかかる短いステップ、そして徐々に安くなるのではなく、最初から価格が圧倒的に低いという、根本的に異なる価格体系です。 S3の発表は業界横断的に興味をそそり、どうやったらそれが可能になるのだろうかと疑問の声がありました。大量に仕入れと供給をするサプライヤであっても、バイト単位の販売に関しては実施しないでしょう。本当にその内容がいいと思いましたし、信頼できるストレージシステムとして、S3を使って作成したソースコードを保存していました。その時は、すこし格好悪いですが、とがっていて、大きなことを始めたいという気持ちでアプリを書いていました。 アプリを書いてから動かすまで何日かかかり、デバッグとテストを延長し、月末になって、私はVisaの請求を受け取りました。もちろん、S3が非常に低コストである事は知っていましたが、すべてのアプリ開発とテストにかかった費用は3.08ドルでした。請求が間違えているのかと思いました。開発が終わっても、テストデータはS3に保存してあったのですが、次の月に受け取った請求は0.07ドルでした。 とても革新的でしたし、当時社内でもブログを書きました。CTOやCEOといった会社のリーダーにもデモをしました。プレゼンにはS3での早期の開発例のひとつであるAl Vermeulenの写真が含まれていて、どうS3が動作するか、本当に他と異なるところを強調しました。私は2つのAWSのサービスに対する請求がありました。ポイントはAmazonがただ演技や少し試してみるといったことで一時的にサービスを提供しているわけではなく、インフラサービスの提供の真に新たな方法であると本当に考えられたものでした。当時は、ストレージが最初のリリースで、その後まもなくコンピューティングのサービスが始まりました。 私は心底AWSに興味を持ち、2007年までユーザグループのミーティングにも参加していました。Amazonでプレゼンも実施し、最終的には2008年後半にAmazonに入社しました。 AWSのエンジニアチームのメンバーとなりましたが、私の第一印象はとてもスピードが速いと、言い表せるのではないでしょうか。他の会社では、決定は素早くなされ新たなアイデアはソースコードになったとしても、最終的にお客様が利用できるようになるには大陸移動と同じくらい時間がかかる、いわゆるエンタープライズITのペースになります。前職では、半分冗談で「我々はお客様が必要かどうか10年に2度リリースすればよい」と考えていました。AWSでは、機能はすぐにリリースされ、追えないくらいになっています。 他に面白いストーリーとしては、エンジニアチームの議論をどうまとめるかです。議論はしばしば起こり、積極的なディベートになります。決定事項はさらなる情熱や信念が加わりますが、最終的にはデータに基づいた判断がなされます。AWSでは、戦略とお客様が何を必要としているのかの代わりに、我々が便利と思うものを見つけリリースし、広くお客様へのサービスとして普及するかどうか見極めてから投資をします。よいサービスが最高のサービスに素早く育つわけです。 以前の役割の中のいくつかで、このような建設的な議論が生活よりも多くを占め、ここ数年間の非生産性に終止符を打ちます。AWSならお客様の使用データからデータを発見し、素早くアクションにつなげられます。ディベートから成果物ではなく、その逆もあります。多くの労力をお客様が判断します。このような労力からソリューションが提供できるようになるのです。成果物のスピードはお客様が使うことでさらによくなることから、AWSはエンジニアにとってはエキサイティングな環境です。 イノベーションの証明となるのはお客様のコミットメントで、偽りなく、お客様のコミットメントの表れが全社の取り組みを変えます。Netflixは100%の移行を公で決めた最初の企業です。 2010 Netflix 2013 Kempinski Hotels 2013 Suncorp Group 2014 Infor 2014 Nippon Express 2014 Notre Dame University 2014 National Democratic Institute 2015 The Guardian Media […]

Read More

Redshiftアップデート:テーブル単位でのリストアが可能に

Amazon Redshiftにテーブル単位でのリストア機能が追加されました。これまではスナップショットからのリストアではクラスタ全体をリストアするという方法でしたが、これが表単位で戻せるようになったことで、一部の表の操作ミス等の修復等の用途に使いやすくなりました。 以下はリリースノートの翻訳です。 == Amazon Redshiftのスナップショットから、クラスター全体をリストアするのではなく、表単位でリストアが可能になりました。この新機能を使うことでアクシデントで削除してしまった表を復活させたり、意図しない方法で更新や削除をしてしまったデータを元に戻すことが可能になります。スナップショットから表を復元するには、管理コンソールでクラスターの”Table Restore”のタブをクリックし、”Restore Table”ボタンを押してください。 注意点としては、テーブルのリストアは稼動しているクラスターから取得したスナップショットを同じクラスターに戻す場合にのみ利用できるという事です。また、そのスナップショットはバージョン1.0.1036もしくはそれ以降のバージョンで取得されたものである必要があります。詳しくはAmazon Redshift Cluster Management GuideのRestoreing a Table from a Snapshotをご覧ください。(訳注:本エントリ執筆時点では日本語版にはまだ記載がありませんでした。その場合は英語に切り替えてご覧ください) 原文:https://aws.amazon.com/jp/about-aws/whats-new/2016/03/amazon-redshift-now-supports-table-level-restore/ 翻訳:下佐粉 昭(@simosako)  

Read More

週刊 AWS – 2016 年 2 月 29 日

週刊 AWS – 2016 年 2 月 29 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 2 月 29 日 AWS Import/Export Snowball でエクスポートがサポートされるようになったことを発表しました。 欧州 (フランクフルト) リージョンでの Amazon CloudWatch Events の提供開始を発表しました。 南米 (サンパウロ) リージョンにおける VPC ClassicLink および ClassicLink DNS のサポートについて発表しました。 AWS Storage Gateway で EMC Networker 8.x と ゲートウェイ VTL の組み合わせがサポートされるようになったことを発表しました。 AWS Windows and .NET Developer Blog が、ASP.NET […]

Read More

AWS Import/Export Snowball Update – エクスポートがすぐに利用可能

AWS Import/Export Snowball が昨年の AWS re:Invent でローンチされました (詳細については、ブログポスト 「AWS Import/Export Snowball � Transfer 1 Petabyte Per Week Using Amazon-Owned Storage Appliances」を参照)。 ローンチ時には、このアプライアンスベースのモデルを使用して、大量のデータ (通常 10 TB 以上) を AWS に移行することができました。Snowball のこの機能はとてもうまく動作し、すでに多くのお客様が大いに活用しています。 Snowball を使用したエクスポート 現在、データエクスポート操作で同じモデルを利用できます。数 TB または数 PB のデータを AWS で収集、生成、または保存しており、これらの操作をネットワーク接続よりもはるかに高速に処理したい場合、AWS Import/Export Snowball を代わりに使用できるようになりました。 必要な操作は、単に AWS マネジメントコンソールにログインし、エクスポートリクエストを作成して、エクスポートするデータを指定するだけです。単一のリクエストで、1 つ以上の Amazon Simple Storage Service (S3) バケットを対象にすることができます。このサービスは必要なアプライアンスの数を判断し (アプライアンスごとに 50 TB […]

Read More