Category: General

週間 AWS – 2016 年 3 月 7 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 7 日 AWS CodeCommit 向けの通知をスタートしました。 新規の AWS アカウントがデフォルトで長い EC2 リソース ID に設定されるようになったことを発表しました。 AWS セキュリティブログに、AWS IAM および AWS CloudFormation を使用して VPC へのアクセス制限を自動化する方法を掲載しました。 Botmetric に、AWS セキュリティの脅威に対する取り組みの現状: アクセスコントロールが掲載されました。 CloudCheckr で、AWS の多様なサービスを有効に活用するための 5 つのヒントが共有されました。 CloudEndure に、2016 年に必読のクラウドコンピューティング書籍トップ 5 が掲載されました。 Cloud Academy から、AWS CloudWatch によるログ管理の一元化シリーズのパート […]

  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は、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。 暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。 […]

  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 […]

  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の発表は私にとって開眼した出来事です。テクノロジ業界は毎日１００もの発表をしていますが、多くを目にすることはありません。多くの場合、興味がわくようなものではないのです。でも、S3の発表は革新的でした。特に驚いたのはサービスの価格でした。我々が当時支払っていたデータセンターの冗長ストレージの２桁近く安い価格だったのです。でも、さらなる破壊的な事もあり、サービスを利用するにはクレジットカードのみ登録すればよいという事でした。経理の承認の裁可もいらないし、相見積を取る必要もなく、ベンダーを選ぶ必要もなく、ベンダーとの交渉も必要なく、データセンターのスペースを探す必要もありませんでした。ただ、サインアップして使い始めることができたのです。 注目すべきことは、低価格と設定の容易さで、いわゆるトラディショナルなエンタープライズの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 […]

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）  

週刊 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 […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 2 月 22 日 Amazon RDS Update と MySQL 5.7 のサポートを発表しました。 AWS Mobile SDK for Android での AWS IoT のサポートを発表しました。 テルアビブでの AWS Pop-Up Loft について発表しました。 CloudCheckr が 5 つの一般的な AWS コスト問題について調査すべき項目と迅速に解決する方法を掲載しました。 AWS Data Pipeline でのオンデマンドパイプラン実行を発表しました。 AWS Mobile Development Blog が AWS SDK for .NET の Unity v3 サポートが正式リリースとなったことを発表しました。 N2WS が EBS […]

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 […]

みなさん、こんにちは。Partner SA酒徳です。 本日、AWS Partner Meetingが品川で行われ多くのパートナー様が参加されました。Parnter Meetingは４半期に一度の頻度で開催されていますが、本日は2016年度初回ということで、去年１年間を通じ活躍をされたパートナー様を表彰するAPN Awardの授与式も合わせて行われました。 Partner Meetingの速報として、本日受賞されましたパートナー様とその受賞理由をご紹介させて頂きます。今年は10の賞に対し13社の受賞パートナー様が誕生いたしました。おめでとうございます！ ・APN Partner of the Year 2015 【受賞パートナー様】：アイレット株式会社 様 【受賞理由】数多くのAWS関連ソリューション、10以上の顧客事例のリリースや 積極的なメディア活動を通じ、メディア、エンターテイメント、スタートアップ企業のみならず、大手エンタープライズ企業のUnix Migrationなど更なるAWSビジネスの拡大への貢献が評価され受賞となりました。 【アワード内容】年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様。 ・APN Reference of the Year 2015 【受賞パートナー様】：株式会社野村総合研究所 様 【受賞理由】世界最大級のSAP基幹システムの稼働。2015年早期の事例公開により、その後における多くのSAP案件ならびに大型基幹システム移行において顧客の導入意思決定に大きく寄与したことが評価され受賞となりました。 【アワード内容】お客様公開事例において、AWSが企業のビジネスに大きく貢献する事を示し、市場に大き な影響を与えたAPNパートナー様 APN Cloud Package Business of the Year  2015 【受賞パートナー様】：ウイングアーク１ｓｔ株式会社 様 【受賞理由】SVF Cloudの運用Platformとして、信頼と可用性の向上を目的とし、AWSを全面採用。特に、Amazon Aurora・Kinesisなどの多くのサービスを積極採用頂きました。大規模ユーザ向けには大量の配送伝票を出力する案件提案が評価され受賞となりました。 【アワード内容】AWSの顧客に高い付加価値を提供した。または市場拡大に寄与したPackage on AWS または SaaSを提供したパートナー様。 APN Rookie of the […]

私は街歩き愛好家です。 新しい街を歩き、裏通りや細い路地を探索し、それらをユニークで特別なものにしているものを見つけることが楽しみです。東京を訪問中、渋谷を歩いている時に驚くようなホビーショップを見つけました。8 階建のビルには、ありとあらゆるホビーのための工具、部品、組み立てキットがありました。(日本にいる私の同僚が書いた) 以下の記事から読み取れるように、このお店「東急ハンズ」は AWS カスタマーです! – Jeff 東急ハンズは、革新的な POS (Point of Sales) システムと EC サイトにより、お客様の体験をより良いものにしています。同社の新しいソリューションについて、同社 CTO の長谷川秀樹様はこう語ります。 小売業である当社は、常にコストを重視しており、DynamoDB の簡単にスケールする機能のおかげで運用のコスト効率が大幅に改善されました。高速で高い可用性、しかもスケーラブルなデータベースを、月当たりわずか数百ドルで使えるようになり、高価なハードウェアやデータベース運用担当者にお金を使う必要はなくなりました。 背景 東急ハンズは、日本で最も人気のある大規模小売店チェーンの 1 つです。雑貨や日本の文具、創作意欲を起こさせる DIY 用品や家庭用品をワンストップで購入できるお店を、日本、シンガポールに 40 店舗、展開しています。更に売り場として EC サイトを運用しており、お客様は PC やモバイル端末を使って 24 時間 365 日買い物ができます。東急ハンズは、同社の急速な成長ペースとビジネス機会創出ペースを維持するために、高速で柔軟、しかもスケーラブルな IT システムを完全に Amazon Web Services (AWS) 上で構築して運用しています。 AWS を使う以前は、東急ハンズの IT システムはオンプレミスのデータセンターに配置されており、データセンターを運用しスケールさせるのは非常に大変でした。東急ハンズは AWS に全てのシステムを移行すること (all-in) を決め、アプリケーションをオンプレミスのデータセンターからクラウドに移行しました。インフラストラクチャ管理を AWS に移管することで、東急ハンズはお客様へより良い価値を提供することに集中できるようになりました。長谷川様曰く、「私は AWS が好きです。なぜなら、時間とリソースをインフラストラクチャの管理ではなく、お客様のための改善に費やすことができるからです。AWS […]