Amazon Web Services ブログ

Amazon Redshift は高速で完全マネージド型のデータウェアハウスです。ペタバイト級のデータを高速なローカルストレージに取り込み、多様なクエリを処理可能なデータウェアハウスを実現可能です。 今年の４月に新機能としてAmazon Redshift Spectrumが発表されました。これはデータをAmazon S3に置いたままロードせずにAmazon Redshiftからクエリする事を可能にする新機能であり、Amazon Redshiftが処理可能なデータサイズをペタバイトから、エクサバイト級に押し上げるものです。データ置き場（Amazon S3）とデータ処理基盤（Amazon Redshift）が分離するということは、単に扱えるデータサイズが増えるだけでなく、これまで以上に多彩なワークロードを実現可能にしました。例えば、ロード時間なしで素早くデータ分析を開始したり、あまりアクセスしない古いデータと頻繁にアクセスするデータの置き場所を変えることで、コスト効率の良いデータウェアハウスを実現しつつ、全期間のデータ分析を実現する等です。 Amazon Redshift Spectrumについての詳細を確認するには、以下の記事を参照してください。 Amazon Redshift Spectrum – S3のデータを直接クエリし、エクサバイトまでスケール可能 データウェアハウスをエクサバイト級に拡張するAmazon Redshift Spectrum Amazon Redshift Spectrumによるセキュリティとコンプライアンスのためのデータベース監査ログの分析 Amazon Redshift Spectrumは北バージニアリージョンから提供を開始し、継続的に利用可能なリージョンを増やしてきました。そして本日からAmazon Redshift Spectrumが東京リージョンで利用可能になりました！ AWSのサービスはリリースした後も新機能が継続的に追加されていきます。Amazon Redshift Spectrumもその例外ではなく、上述のブログには書かれていなかった機能が多数追加されています。本稿ではGA（一般利用開始）から現在までの期間でどのような機能追加、改善があったのかを解説します。 継続的な処理性能の改善 Amazon Redshiftでは内部的な改善による処理性能の向上が継続的に行われています。Amazon Redshift Spectrumでの改善の1つとして、大きいファイルの分割アクセスがあります。GAの時点では１つのファイルを１つのSpectrum層のプロセスが処理していたため、ファイルサイズが巨大だった場合に読み取りがボトルネックになる可能性がありましたが、その後の改善で巨大なファイルは自動的に分割して読み取り処理を行なうように改善されています。（巨大ファイルをそのまま置く事を推奨しているわけではありません。可能であれば利用者の方で適切なサイズに分割しておく事が推奨されます） Amazon Redshift Spectrumのパフォーマンスについては以下の記事も参照してください。 Amazon Redshift Spectrum 10 のベストプラクティス 対応フォーマットの追加 Amazon Redshift Spectrumでは多彩なフォーマットに対応しているのが特長です。CSV、TSVといった区切りファイル、Parquet、RCFileといったカラムナフォーマット等です。そしてGA後も継続的に対応フォーマットが追加されています。例えばカラムナフォーマットのORCファイルや、Regex（正規表現）等がGA後に追加されました。現時点では以下のファイルフォーマットをサポートしています。 AVRO PARQUET TEXTFILE SEQUENCEFILE RCFILE […]

（補足：本記事は2017年7月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります） 何年も前、最初にクラウドベースのデータウェアハウスを構築する可能性について検討を始めた際、我々は、我々の顧客が増え続ける一方の大量のデータを持つ一方で、そのごく一部のデータのみが既存のデータウェアハウスやHadoopシステムに投入され分析に利用されているという事実に直面しました。同時に、これがクラウド特有の特殊事情ではないこともわかりました。エンタープライズストレージ市場の成長率がデータウェアハウス市場のそれを大きく上回る様々な業界においても、状況は同じだったのです。 我々はこれを“ダークデータ”問題と名付けました。我々の顧客は、彼らが収集したデータに利用されていない価値があることに気づいていました。そうでなければなぜそれを保管するコストをかけるでしょうか？しかしながら、彼らが利用できるシステムは、これらのデータ全てを処理するには遅すぎ、複雑すぎ、高すぎたため、データのサブセットのみを利用することになりました。彼らはいつか誰かが解決策を見出すことへの楽観的な期待とともに、これらのデータを保持し続けました。 Amazon Redshift はダークデータ問題の解決に寄与することから、AWSサービスの中でも最も成長の速いサービスの一つとなりました。このソリューションは大半の代替案に比べ、少なくとも一桁は安価で、かつ高速でした。また、Amazon Redshiftは当初からフルマネージドのサービスで、ユーザーはキャパシティやプロビジョニング、パッチ対応、監視、バックアップ等を始めとする様々なDBA課題について頭を悩ませる必要がありませんでした。 Vevo, Yelp, Redfin,Edmunds, NTTドコモなどの多くの顧客が、Amazon Redshiftに移行して、クエリー性能の改善、DBAオーバーヘッドの削減、そして分析コストの低減を実現しました。 我々の顧客のデータは、極めて速いペースで増え続けています。おしなべて、ギガバイトのデータはペタバイトとなり、平均的なAmazon Redshift顧客が分析するデータ量は毎年二倍になっています。我々が、増加するデータを扱う上でお客様の手助けとなる機能群を実装してきた理由はここにあります。例えばクエリースループットを二倍にする、圧縮率を三倍から四倍に改善する、といったことです。これらは、お客様がデータを破棄したり分析システムから削除したりすることを考慮せざるを得なくなる時期を遅らせることができます。しかしながら、ペタバイトのデータを日々生成するAWSユーザーが増えており、こうしたデータはわずか3年でエクサバイトの水準に達します。このようなお客様のためのソリューションは存在しませんでした。もしデータが毎年倍々になるのであれば、コスト・性能・管理のシンプルさに革新をもたらす、新たな、破壊的なアプローチを見付けることを強いられるまで、そう長い時間はかからないでしょう。 今日利用可能な選択肢に目を向けてみましょう。お客様は、Amazon EMRを用いて、Apache HiveなどのHadoopベースの技術を利用することができます。これは実際のところ、非常に素晴らしいソリューションです。抽出と変換のステップを経ることなく、Amazon S3上のデータを簡単かつ低コストで直接操作できるようになるからです。クラスターは必要な時に起動することができ、実行対象となる特定のジョブに合うよう適切にサイジングすることができます。こうしたシステムは、スキャンやフィルター、集計といったスケールアウト型の処理には最適です。一方で、これらのシステムは複雑なクエリー処理には向いていません。例えば、結合処理ではノード間でデータをシャッフルする必要が生じます。巨大なデータと多数のノードが存在する場合、この処理は極めて低速になります。そし結合処理は、重要な分析課題の大半において本質的に重要なものです。 Amazon Redshiftのような、列指向かつ超並列型のデータウェアハウスを利用することもできます。こうしたシステムは、巨大なデータセットに対する結合や集計といった複雑な分析クエリーを、単純かつ高速に実行することを可能にします。特に、Amazon Redshiftは、高速なローカルディスクと洗練されたクエリー実行、そして結合処理に最適化されたデータフォーマットを活用します。標準SQLを用いるので、既存のETLツールやBIツールを活用することもできます。一方で、ストレージとCPU双方の要件を満たすようにクラスターをプロビジョニングする必要があり、データロードも不可欠となります。 いずれのソリューションも強力な特長を備えていますが、お客様はどちらの特長を優先するかの判断を強いられます。我々はこれを「ORの抑圧（※）」と見做しています。ローカルディスクのスループットとAmazon S3のスケーラビリティは両立できない。洗練されたクエリー最適化と高度にスケールするデータ処理は両立できない。最適化されたフォーマットによる高速な結合処理性能と、汎用的なデータフォーマットを用いる様々なデータ処理エンジンは両立できない、などです。しかし、この選択は本来迫られるべきではありません。この規模においては、選択する余裕など到底ないからです。お客様が必要とするのは「上記の全て」なのです。 ※ジム・コリンズが著書「ビジョナリー・カンパニー」で提示した概念。一見矛盾する力や考え方は同時に追求できない。 Redshift Spectrum Redshift Spectrumは、こうした「ORの抑圧」に終止符を打つべく開発されました。Redshift Spectrumによって、Amazon Redshiftを利用されているお客様はAmazon S3上のデータに対し 簡単にクエリーを実行できるようになります。Amazon EMRと同様に、お客様はオープンなデータフォーマットと安価なストレージの恩恵を享受できます。データを抽出し、フィルターし、射影し、集計し、グループ化し、ソートするために、何千ものノードにスケールアウトすることも可能です。Amazon Athenaと同様に、Redshift Spectrumはサーバーレスであり、プロビジョニングや管理は必要ありません。単に、Redshift Spectrumを利用したクエリーが実行されている間に消費中のリソースに対してお支払いいただくだけです。Amazon Redshift自身と同様に、洗練されたクエリーオプティマイザー、ローカルディスク上のデータへの高速アクセス、そして標準SQLの恩恵を得ることができます。そして、他のどのようなソリューションとも異なり、Redshift Spectrumはエクサバイト級ないしはそれ以上のデータに対して、高度に洗練されたクエリーを、わずか数分で実行することが可能です。 Redshift SpectrumはAmazon Redshiftの組み込み機能の一つであり、お客様の既存のクエリーやBIツールはシームレスにご利用いただくことができます。背後では、我々は複数のアベイラビリティゾーンに跨がった何千ものRedshift Spectrumノードのフリートを運用しています。これらのノードは、処理する必要があるデータに基づいて透過的にスケールし、クエリーに割り当てられます。プロビジョニングや利用の確約は不要です。Redshift Spectrumは同時実行性にも優れています。お客様は任意のAmazon S3上のデータに対して、複数のAmazon Redshiftクラスターからアクセスすることができます。 Redshift Spectrumクエリーのライフサイクル Redshift Spectrumクエリーのライフサイクルは、クエリーがAmazon Redshiftクラスターのリーダーノードに送信された時に始まります。リーダーノードはクエリーを最適化し、コンパイルし、その実行命令をAmazon Redshiftクラスターのコンピュートノード群に送ります。次に、コンピュートノード群は外部テーブルに関する情報をデータカタログから取得し、当該クエリーのフィルターと結合に基づいて、無関係なパーティションを動的に取り除きます。コンピュートノードはまた、ノード上でローカルに利用可能なデータを精査して、Amazon S3内の関連するオブジェクトだけを効率的にスキャンするようプレディケイトプッシュダウンを行います。 Amazon Redshiftコンピュートノードは、続いて、処理する必要のあるオブジェクトの数に基づいて複数のリクエストを生成し、それらをRedshift Spectrumに一斉に送ります。Redshift Spectrumは、AWSリージョンごとに何千ものAmazon EC2インスタンスをプールしています。Redshift […]

本日は、AWS と Microsoft が、どのディープラーニングフレームワークを選択するかにかかわらず、すべての開発者向けに機械学習テクノロジーの速度、柔軟性、アクセス性を向上させることを主眼とした新しい仕様を発表しました。この連携による最初の結果が、新しい Gluon インターフェイスです。これはあらゆるスキルレベルの開発者がディープラーニングモデルのプロトタイプ作成、構築、トレーニングを行えるようにする、Apache MXNet のオープンソースライブラリです。このインターフェイスにより、トレーニング速度を犠牲にすることなく、ディープラーニングモデルの作成プロセスを大幅に簡略化できます。 Gluon の 4 つの重要な利点と、それを示すサンプルコードを示します。 (1) シンプルで理解しやすいコード Gluon では、シンプル、明瞭、簡潔なコードを使ってニュートラルネットワークを定義できます。事前定義されたレイヤー、オプティマイザ、イニシャライザを含む、プラグアンドプレイのニュートラルネットワーク構築要素のフルセットを入手できます。これにより、基盤となる複雑な実装詳細の多くが排除されます。次の例では、わずか数行のコードでシンプルなニュートラルネットワークを定義する方法を示しています。 # 最初のステップはモデルの初期化です net = gluon.nn.Sequential() # Then, define your model architecture with net.name_scope(): net.add(gluon.nn.Dense(128, activation=”relu”)) # 最初のレイヤー – 128 ノード net.add(gluon.nn.Dense(64, activation=”relu”)) # 2 番目のレイヤー – 64 ノード net.add(gluon.nn.Dense(num_outputs)) # Output layer 次の図に、ニュートラルネットワークの構造を示します。 詳細については、こちらのウォークスルーに移動して、Gluon ニュートラルネットワーク構成要素を使って multilayer perceptron (MLP) と呼ばれるシンプルなニュートラルネットワークを作成する方法を参照してください。より高度なユースケース向けに、ニュートラルネットワークのパーツをゼロから作成することも簡単です。Gluon […]

先日のCloud Roadshow 2017 広島、名古屋、大阪では、KeyNoteの中でAWSの円払い対応および日本準拠法対応についてみなさんにご案内いたしました。本ブログの中で2回連載という形でそれぞれ、支払方法の円対応、日本準拠法切り替えについてご案内をいたします。 実は、AWSの支払い通貨変更機能は、2015年2月にお客様からのご要望受けて実現してる機能ですが、新しくAWSのご利用をご検討いただいている皆様に改めてお伝えしたいこと、また管理者画面のデザイン変更などで過去ブログで記載された手順と少し変更が入っているため、改めてみなさんにその特徴・注意点と手順を共有させていただきます。 [特徴] 管理者画面での変更だけで切り替え作業が完了します 対応しているクレジットカードはVISAとMasterカードです MarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます AWS内部ではドルで計算され、月末の利用料集計時に、その時点でのAWSが定めるレートをもとに円に自動計算されます 月額のAWSご利用額がドル換算で過去3か月平均が2000ドル以上ある場合は、請求書切り替えも可能となります。 請求書払いもクレジットカードと同様にMarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます [手順] それでは手順についてみていきましょう。まず管理者画面にログインしてください。トップページがでてきます。 右上のアカント名が、みなさんが設定を行おうとしているアカウント名が正しく表示されていることを確認してください。なお、AWSマネージメントコンソールはアカウント開設時期や設定状態などで異なるデザインが表示される方もいらっしゃいますが、エラーではありませんので安心してください。 右上のアカウント名を選択してください。 アカウントを選ぶと以下の画面が出てきます。 オレンジ色の箇所にはみなさんのアカントに登録された情報が出てきます。左側の「お支払方法」を選択してください。 お支払いに使用されているクレジットカード情報が表示されます。その右上にUSDとなっている箇所がありますのでそちらをクリックしてください。 「お支払通貨の設定」の右側にある「編集」を選んで通貨を選んでください。 全部で13種類の通貨が選べるようになっています。日本円の場合はJPYを選んでください。以上で切り替えは終わりです。作業を行った月のAWS利用分から支払通貨変更が反映されます。 [請求書払いへの切り替えについて] 請求書払いへの切り替えの場合、AWSの月額ご利用額がドル換算で過去三か月の平均が2000ドル以上であれば、サポートセンターで「新規ケースの作成」をクリックし、「アカウントおよび請求サポート」まで変更をご依頼ください。 2000ドルに満たないが、今後ご利用予定がある場合は、担当アカウントマネージャへのご連絡、もしくはこちらからご連絡ください。 -プロダクトマーケティング エバンジェリスト 亀田

Amazon Redshiftは高速で完全マネージド型のデータウェアハウス（DWH）です。ペタバイト級までスケールアウトが可能であり、Amazon Redshift Spectrumを利用することでAmazon S3上に保存されたエクサバイト級のデータにロード無しでクエリを実行することも可能です。 Amazon Redshiftがリリースされた当初からご利用いただいている方であれば、当初はHDD搭載のDW1と呼ばれるノード1種類しか無かったことをご記憶かと思います。続いてSSDを搭載した新しいノード追加され、DW1(HDDベース）とDW2(SSDベース）の2タイプから選択可能になりました。 その後、DW1の後継がリリースされる際にHDDベースはDense Storage (DS) に、SSDベースはDense Compute (DC)とそれぞれの特性を表した名前に整理され、DS1（旧DW1)の後継としてDS2がリリースされました。DS2の登場はDS1ユーザから驚きをもって迎えられました。DWHとしての性能が大きく向上しつつ、ノードの価格は据え置きだったからです。 次はDense Compute (DC)の番です。DC2が本日より利用可能になりました！ 第二世代のDense Computeノード DC2はDC1の後継となるノードであり、高いスループットと低いレイテンシを必要とするDWHワークロードのために設計されています。CPUはIntel E5-2686 v4(Broadwell)になり、高速なDDR4メモリを搭載。ストレージはNVMe接続のSSDです。 私達はAmazon Redshiftがこのより高速なCPU、ネットワーク、ストレージの性能をDC2で十分に発揮できるようチューニングを行い、結果としてDC1との同一価格構成での比較で最大2倍のパフォーマンスを発揮しています。DC2.8xlargeノードではスライスあたりで2倍のメモリを搭載しており、ストレージレイアウトの改善によって30%多いデータが保管できるようになりました。これらの改善がされた新世代のノードを旧世代と同じ価格で提供します。 DC2.8xlargeではパフォーマンスを最大化するためにスライス数が変更されています。旧世代のDC1.8xlargeでは1ノードあたり32スライスでしたが、DC2.8xlargeでは16スライスに変更されています。DC2.largeはDC1.largeと変わらず1ノード2スライスのままです。 このため、DC1.8xlarge (もしくはDS)からDC2.8xlargeへ移行するためにはクラスターのリサイズが必要になります。DC1.largeからDC2.largeへの移行については、リサイズもしくはDC1で取得したスナップショットからの作成が可能です。 本日より利用可能です DC2ノードはUS East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific […]

自動運転車は近い将来に車道を埋め尽くすことが見込まれています。ディープラーニングと自動運転のアプリケーションの進歩がこの自動運転車を実現しました。このポストでは、Amazon AI サービスを活用したリモートコントロール (RC) 自動車を製作する方法のチュートリアルを紹介していきます。 通常、各自動運転車には高度なテレメトリを提供する多くのセンサーが搭載されています。このテレメトリは、個々の自動車の運転と共に、ユーザーエクスペリエンスを向上するために使用できます。こういった向上の例には、スマートドライブルーチングによる時間の短縮、車両航続可能距離と効率の向上や安全性とクラッシュリポートの増大などがあります。AWS では、TuSimple などのカスタマーが Apache MXNet を使用した繊細な自動化プラットフォームを構築しました。最近では、TuSimple が 200 マイルドライバーレス運転を成功しました。 ディープラーニング、AWS IoT と人工知能 (AI) の技術による運転の認知を目的として、AWS はワークショップ形式のハッカソンである Robocar Rally を re:Invent 2017 で開催します。このポストは、開発者を対象に自動化 AI 技術を学習し、ハッカソンに備えるためのブログポストと Twitch ビデオシリーズの第 1 弾となります。ハッカソンについての詳細は、Robocar Rally 2017 をご覧ください。 このチュートリアルでは、Donkey という名称のオープンソースプラットフォームを活用します。希望する場合には、お手持ちの 10 分の 1 スケールの電気自動車で体験することもできます。ただし、Donkey プロジェクトで使用される 16 分の 1 スケールの RC カーの使用がより推奨されます。 次の 2 本のビデオでは、これから説明するチュートリアルを使用して AWS で製作した 2 台の自動車を紹介しています。 […]

このブログは、Y-cam Solutions のシニア開発者である Siva K. Syamala によるゲストブログポストです。Syamala 女史の言葉によると、「Y-cam は高性能なセキュリティビデオソリューションのプロバイダとして、すべての人々に簡単で扱いやすいスマートホームセキュリティを提供してくことをビジョンに掲げています」。 ホームセキュリティは、ホームオートメーションと IoT の活用においてとても重要な要素です。Y-cam Solutions Limited は Amazon をその基盤援助として、世界各地からスマートフォンによるモニタリングと制御ができるスマートセキュリティシステムを提供してきました。アラート、通知、そしてシステムをコントロールする方法を改善するために、Y-cam は Amazon Polly を使用して、ユーザーが会話によってセキュリティシステムと交信できる最新型の AI サービスを提供します。 当社サービスの作動方法 アラームが発生すると、Twilio を通じて音声によるカスタマーへの通知が行われます。呼び出しが確立されたら、Twilio は TwiML の指示に従って手順を実行し、Amazon Polly から取得する音声構成を使用してカスタマーにストリーミングを開始します。呼び出しの受信者は、携帯電話のキーパッド (DTMF コード) のボタンを押して回答します。DTMF コードによって、当社のサービスは指定されたアクションを実行し、Amazon Polly から取得する音声合成への TwiML 指示を返します。実際により近い会話を実現するには、Amazon Polly が素早く返答することがとても重要となります。遅延と待機時間は不満を引き起こし、受信者が電話を終了してしまう可能性を増大させます。 以下は、アラームが発生した場合のカスタマーへの通話を示すオーディオクリップのサンプルです。 アーキテクチャ   Amazon Polly の呼び出し 次の Java コードは、Amazon Polly から音声合成がリクエストされ、S3 バケットに保存されることを示しています。

Amazon Linux AMI の最新バージョン (2017.09) が、すべての AWS リージョンの現行世代の EC2 インスタンスで利用可能になったことをお知らせします。AMI には、EC2 上で実行するアプリケーションのために安定した安全で高性能な環境を提供するように設計された Linux イメージのサポートと保持が含まれています。 簡単なアップグレード 次の 2 つのコマンドを実行して既存のインスタンスをアップグレードし、再起動します。 $ sudo yum clean all $ sudo yum update 盛りだくさん AMI には多くの新機能が含まれており、そのうち多くはお客様のリクエストに応えて追加されたものです。概要は次をご覧ください。 Kernel 4.9.51 – Based on the 4.9 の安定したカーネルシリーズをベースにしたこのカーネルには、ENA 1.3.0 ドライバーと TCP Bottleneck Bandwidth and RTT (BBR) のサポートが含まれています。私の投稿 Elastic Network Adapter – High-Performance Network Interface for […]

私はよく Amazon のイノベーション文化についてプレゼンテーションを行いますが、Amazon の創設者 Jeff Bezos の意義深い引用を取り上げたスライドから始めることが多くあります。 お客様にお会いして、私たちがお客様の創造性や夢の追及をどのように支援できているかについて知るのは楽しいものです。今年に入って、Coca-Cola Company の Patrick と歓談し、AWS Step Functions や他の AWS のサービスを使用して Coke.com の Vending Pass プログラムをサポートした方法を教えてもらいました。このプログラムでは、Coca-Cola Vending Pass を使用したモバイル支払いをサポートしている自動販売機で製品を購入することで、ドリンクがプレゼントされます。参加者が NFC 対応電話をスワイプすると Apple Pay または Android Pay で購入が完了し、自動販売機で個人が識別されてクレジットを獲得できます。このクレジットを貯めることで、将来自販機で無料で購入できます。 スワイプ後、SNS トピックと AWS Lambda 関数の組み合わせにより既存のバックエンドコードに対する 1 組の呼び出しが開始され、販売ポイントがカウントされて参加者の記録が更新されます。残念ながらバックエンドコードは反応が鈍く多少のタイミング依存性があり、更新が行われず Vending Pass 利用者が混乱する可能性がありました。この問題に対する初期のソリューションは非常にシンプルでした。Lambda コードを変更して 2 つの呼び出しの間に 90 秒間のディレイを含めたのです。これにより問題は解決しましたが、処理時間がかかるのはいいことではありませんでした (Lambda 関数の使用料金は 100 ms 間隔のリクエスト所要時間に基づいています)。 ソリューションの費用対効果を向上させるため、チームは AWS […]

本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。 Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見することがあります。これは問題になっているコードの変更を探すことを困難にし、不必要なストレージ料金も引き起こします。以前は、レポジトリをクリーンアップするには、手動で古いイメージを削除するのに時間を費やしたり、スクリプトを書いて実行する必要がありました。 今日からライフサイクルポリシーを使うことで、古いコンテナイメージを自動的に削除するためのいくつかのルールを定義することが可能になりました。ルールが実行された時に影響を受けるコンテナイメージを実際にプレビューで確認することも可能です。これによって、レポジトリはより組織化され問題になっているコードのリビジョンを簡単に見つけられ、そしてストレージコストも抑えられます。 それでは、ライフサイクルポリシーがどのように動くかを見てみましょう。 基本的なルール コンテナを使ってコードをデプロイすることの最も大きい利点の1つは、素早く簡単に過去のバージョンにロールバックできるということです。これにより、リスクを抑えてデプロイすることが可能になります。なぜならば、もし何かおかしかったら、過去のコンテナのバージョンに戻して、失敗したデプロイ以前の状態でアプリケーションを動作させることが簡単にできるからです。多くの人は、数個前のバージョンにロールバックするということはおそらくしないでしょう。もしこういった状況であれば、1つのシンプルなライフサイクルルールとしては、最新の30イメージを保持するというものが考えられます。 最新の30イメージ ECRレジストリの中から、Dry-Run Lifecycle Rules, Addを選択します。 Image Statusには、Untaggedを選択します。 Match criteriaでは、Count TypeにImage Count More Thanを入力します。 Count Numberには30を入力します。 Rule actionにはexpireを選択します。 Saveを選択します。どのイメージがクリーンアップされるかを見るには、Save and dry-run rulesを選択します。 もちろん、数による保持ではなく、コンプライアンスの理由で期限によっていくつかのイメージを保持したいチームも存在します。そういった場合には、90日以前のイメージをクリーンアップするという選択もできます。 最新90日分 先程作成したルールを選択し、Editを選びます。パラメータを変更して、タグがついていないイメージを90日だけ保持する様に変更します: Match criteriaでは、Count TypeにSince Image Pushedを入力します。 Count Numberには90を入力します。 Count Unitにはdaysを選択します。 タグ もちろん90日というのは任意の時間に設定できますが、ある特定の種類のイメージだけもっと長い期間保持するようなポリシーが必要なこともあります。そういった場合で、でも大掃除は続けたいというときには、タグがつけられたイメージだけ削除するというのを検討することも可能です。 こちらのルールのリストは、タグが無いもの、development、staging、そしてproductionなイメージへのルールの例をまとめてみたものです: タグのないイメージは90日以前を削除 developmentタグのついたイメージは90日以前を削除 stagingタグのついたイメージは180日以前を削除 productionタグのついたイメージは1年以前を削除 ご覧頂いた通り、新しいAmazon ECRのライフサイクルポリシーは強力で、必要なイメージだけを保持するのが簡単になり、もう必要のないイメージをクリーンアップしてくれます。この機能は本日よりAmazon […]