170
Amazon SNS SQS ITライブラリーより pdf 100冊) http://itlib1.sakura.ne.jp/ 解説 (全170ページ)

Amazon SNS とSQSitlib1.sakura.ne.jp/test380/pdfichuran/0453/021-Amazon...①Amazon SQS を他のAWS インフラストラクチャウェブサービスに統合して、 アプリケーションの信頼性と柔軟性を向上させることができます。②Amazon

  • Upload
    others

  • View
    10

  • Download
    0

Embed Size (px)

Citation preview

Amazon SNS と SQS

ITライブラリーより (pdf 100冊)http://itlib1.sakura.ne.jp/

解説

(全170ページ)

本資料の関連資料は下記をクリックして

PDF一覧からお入り下さい。

ITライブラリー (pdf 100冊)http://itlib1.sakura.ne.jp/

目次番号 453番 AWS詳細解説 全33冊 計6,100ページ

2

3

4

5

6

7

補足:Amazon Simple Notification Service

(Amazon SNS)

Amazon Simple Notification Service(Amazon SNS)は、クラウドからの

メッセージ通知のセットアップ、作業、送信を簡単にするウェブサービスです。

アプリケーションからメッセージを発行し、登録者や他のアプリケーションに

迅速に配信するための、スケーラブルかつ柔軟で、費用対効果の高い

機能を備えています。

8

また、ウェブスケールの コンピューティングを開発者が簡単に利用できるよう

設計されています。

Amazon SNS は、「publish-subscribe」(pub-sub)メッセージング

パラダイムに従っています。

ここでは 「プッシュ」 メカニズムを用いて通知が配信されるため、新しい情報や

更新のために定期的に確認または 「ポーリング」を行う必要がありません。

9

事前の最小限度の開発努力を必要とするシンプルな API のおかげで、

メンテナンスまたは管理諸経費がかからず、またその従量制の価格設定により、

Amazon SNS は開発者に、彼らのアプリケーションに強力な通知システムを

簡単に統合するための しくみが提供されています。

Amazon SNS サービスでは、アプリケーション、ワークフローシステム、

タイミングの重要な情報更新、モバイルアプリケーション、そして通知を必要

とする その他あらゆる アプリケーションのモニタリングなど、幅広く多様な

ニーズがサポートされます。

10

例えばAmazon SNS は、分散型コンピューターアプリケーション間で

イベントを中継、データストア間でデータを移動、またはビジネスシステム内の

記録を更新するためのワークフローシステムで使用することができます。

検証、承認、在庫変更、発送ステータスに関するイベント更新と通知は、

エンドユーザーだけでなく、関連する システムコンポーネントにも直ちに

配信されます。

11

Amazon SNS の別の使用例は、タイミングの重要なイベントをモバイル

アプリケーション やデバイスに リレーすることです。

Amazon SNS は信頼性が高くスケーラブルなため、リアルタイムイベントが

欠かせないアプリケーションを開発する開発者にとって、これが大きな

利点となっています。

12

13

補足: message queueing, ( MQ)

メッセージキューイングとは、異なるアプリケーションプログラム間で動作を連携

させてデータを交換させる際の方式のひとつで、送るデータをキューと呼ばれる

データ領域に保持し、データを受ける側の処理が完了するのを待たずに

次の処理へ移る方式のことである。

メッセージキューイングが導入されることによって、送信する側はキューに

データを置くだけで、送り先と同期できなくても確実にデータを送り届ける

ことができる。

14

接続が途絶えるような状況にあっても、アプリケーションが

対処しなくてもメッセージが確実に届く。

メッセージキューイングによって、アプリケーション間連携は緩やかな

ものになり、柔軟に統合することが可能になった。

15

連携の能率は向上し、待ち時間にバッファリングを行なうためのデータ領域も

節約されるので、パフォーマンスが向上することもある。

プログラム開発の段階でアプリケーションの同期・連携を顧慮する

必要もなくなった。

16

Amazon Simple Queue Service (SQS)

Amazon Simple Queue Service(SQS)は、高速で、信頼性が高く、

スケーラビリティに優れ、十分に管理されたメッセージキューサービスです。

SQS を利用すると、簡単かつコスト効率良く、クラウドアプリケーションの

コンポーネントを切り離すことができます。

SQS を使用すれば、どんな ボリュームのデータでもあらゆるレベルの

スループットで転送できます。

17

転送時にメッセージが失われることも、他のサービスが常に利用可能である

必要もありません。

SQS を使用すると、可用性の高いメッセージングクラスターの運用と

スケーリングという管理上の負担を軽減しつつ、使用した分についてのみの

低額の料金を支払うことができます。

18

19

20

Amazon Simple Queue Service ( Amazon SQS ) は、コンピュータ間でやり

取りされるメッセージを格納するための、信頼性のある、拡張性の高い、

ホスティングされたキューを提供しています。

Amazon SQS を使用することにより、開発者はメッセージを失ったり、各コン

ピュータが常時利用可能であることを必要とせずに、様々なタスクを実行する

分散アプリケーション コンポーネント間で、簡単にデータを移動することが

できます。

21

Amazon SQS を使用すると、Amazon Elastic Compute Cloud

(Amazon EC2) やその他の AWS インフラストラクチャ Web サービスと

緊密に連携する、分散独立型のアプリケーションを簡単に構築できます。

Amazon SQS は、コンピュータがメッセージを処理するのを待ちながら、

メッセージを格納するために使用できるメッセージ キューへのアクセスを

提供するウェブサービスです。

22

これにより、インターネット上の任意のコンピュータ上で実行可能なメッセージ

キューイング アプリケーションを素早く構築することができます。

Amazon SQS は拡張性が高く、ユーザーは使用したものに対して支払えば

よいので、性能または信頼性を犠牲にせずに、アプリケーションを望む通りに

拡張することができます。

23

これにより、メッセージがどのように格納され、管理されるかについて心配

せずに、洗練されたメッセージベースのアプリケーションの作成に集中する

ことができます。

Amazon SQS をソフトウェア アプリケーションと 共に様々な方法で使用する

ことができます。

24

例えば、以下の作業が可能です。

① Amazon SQS を他の AWS インフラストラクチャ ウェブ サービスに統合して、

アプリケーションの信頼性と柔軟性を向上させることができます。

② Amazon SQS を使用して作業のキューを作成することで、各メッセージは

プロセスにより完了させる必要のあるタスクとなります。1 台または多くの

コンピュータがキューからタスクを読み取り、実行することができます。

25

③キューを使用してマイクロサービスに接続するマイクロサービスアーキ

テクチャを構築します。

④Amazon SQS キューにおいて、ビジネスプロセスに重要なイベントの

通知を保持します。

各イベントはキュー内に該当するメッセージを持つことができ、イベントに

注意する必要のあるアプリケーションはメッセージを読み、処理することが

できます。

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

補足:マネージドサービス 【 managed service 】

フルマネージドサービス full managed service

マネージドサービスとは、通信サービスやITサービスなどの分類の一つで、

サービスの利用に必要な機器などの運用や管理、導入時に必要な機器の

設置や設定なども一体として提供するサービスのこと。

45

VPNやデータセンターサービス ( あるいはサーバホスティングサービス、

クラウドサービス ) などでよく用いられる分類で、本来のサービスに付随して

発生する業務をまとめて請け負う一種のアウトソーシングサービスである。

そのようなサービスを提供する事業者を

MSP ( Managed Service Provider ) と呼ぶことがある。

46

サーバの運用であれば、機材の入手・設置からOSなど基本的なソフトウェア

の導入(インストール)、運用中の死活監視、障害発生時の再起動、機材故障

時の交換、24時間365日の電話やメールによるサポートなどが含まれる

ことが多い。

47

補足: 分散キューイング

分散キューイングとは、あるキュー・マネージャーから別のキュー・マネージャーに

メッセージを送信することです。

受信キュー・マネージャーは、同じマシン上に置くことも別のマシン上に置く

こ ともでき、近くにあっても遠方にあってもメッセージを受信できます。

48

49

50

補足: 疎結合 loose coupling

疎結合とは、細分化された個々のコンポーネント同士の結びつきが比較的

緩やかで、独立性が強い状態のことである。

疎結合では、個々のコンポーネント同士は相互に連携しているが、相互に

依存している余地が少ない。

51

そのためコンポーネント間の連携をあまり顧慮せず、それぞれの

コンポーネントを交換したり改良したりするような柔軟な対処を行うことができる。

疎結合に対して、このコンポーネントが密接に連携している状態は密結合と

呼ばれている。

52

密結合状態のシステムは、動作は高速であるが、一方のコンポーネントが

異常をきたしてしまうと他方のコンポーネントもその影響を受けてしまう。

疎結合は マルチプロセッサシステムのようなハードウェア的なものから、

アプリケーションソフト のような ソフトウェア的なものまで、幅広く見られる

状態である。

53

54

55

56

57

58

59

60

61

62

63

キューとメッセージの識別子

Amazon SQS では、次の 3 つの識別子が使用されるため、

これらについて理解しておく必要があります。

①キュー URL

②メッセージ ID

③受信ハンドル

64

①キュー URL

新しいキューを作成するときは、すべてのキューの範囲内で一意なキュー名を

指定する必要があります。

最新の WSDL および以前のバージョンの両方を使用してキューを作成した

場合でも、すべてのキューの名前空間は 1 つです。

65

Amazon SQS では、作成した各キューにキュー URL という識別子が

割り当てられます。

この識別子には、キュー名と、Amazon SQS により決定される他の

コンポーネントが含まれます。

キューでアクションを実行するときは必ず、そのキュー URL を指定します。

66

② メッセージ ID

各メッセージは、システムにより割り当てられたメッセージ ID を受け取ります。

この ID は、SendMessage レスポンスで Amazon SQS により返されます。

この識別子はメッセージの識別に役立ちますが、メッセージを削除するには、

メッセージ ID ではなくメッセージの受信ハンドルが必要です。

メッセージ ID の最大長は 100 文字です。

67

③受信ハンドル

キューからメッセージを受信するたびに、そのメッセージの受信ハンドルを

受け取ります。

ハンドルは、メッセージ自体ではなくメッセージ受信の操作と関連付けられます。

68

メッセージを削除したり、メッセージ可視性を変更したりするには、メッセージ ID

ではなく受信ハンドルを指定する必要があります。

つまり、メッセージを削除する前にメッセージを受信する必要があります

(メッセージをキューにおいてから回収することはできません)。

受信ハンドルの最大長は 1024 文字です。

69

70

71

72

73

74

75

76

77

78

79

80

81

可視性タイムアウト Visibility Timeout

システム内の消費コンポーネントがキューのメッセージを受信および処理する

ときでも、そのメッセージはキューに残ったままです。

Amazon SQS が自動的に削除しないのはなぜでしょうか。

82

これはシステムが分散されているため、コンポーネントがそのメッセージを

実際に受信するという保証がないからです(メッセージを受信する前に

接続が切断されたり、コンポーネントで障害が発生する可能性があります)。

したがって、Amazon SQS はメッセージを削除しません。

代わりに、消費コンポーネントがメッセージを受け取って処理した後、

キューからメッセージを削除する必要があります。

83

コンポーネントがメッセージを受信した直後、そのメッセージはまだキューに

あります。

ただし、システム内の他のコンポーネントが、そのメッセージを再度受信

および処理することは望ましくありません。

したがって、Amazon SQS では、可視性タイムアウトによりその

コンポーネントがブロックされます。

84

つまり、このタイムアウトの期間、他の消費コンポーネントがそのメッセージを

受信および処理できなくなります。

次のスライドの図はこの概念を示しています。

85

86

87

88

補足: Spot Instances

スポットインスタンスでは、未使用の EC2 インスタンスに対してユーザーから

価格を提示してもらいます。

これによりユーザーの Amazon EC2 のコストを大幅に削減できます。

(各アベイラビリティーゾーン内の各インスタンスタイプの) スポットインスタンス

の時間料金は Amazon EC2 によって設定され、スポットインスタンスの需要と

供給に応じて変動します。

89

ユーザーの入札価格が現在の市場価格を上回っている限り、ユーザーは

スポットインスタンスを実行できます。

スポットインスタンスは、アプリケーションを実行する時間に柔軟性がある場合や、

アプリケーションを中断できる場合に、費用効率の高い選択肢です。

90

たとえば、スポットインスタンスは、データ分析、バッチジョブ、バックグラウンド

処理、およびオプションタスクに適しています。

スポットインスタンス と オンデマンドインスタンス との主な違いは、スポット

インスタンスは すぐに起動されない可能性があること、スポットインスタンスの

時間料金は需要に応じて変化すること、およびスポットインスタンスの時間料金や

可用性が変化したときに、Amazon EC2 が個々のスポットインスタンスを終了

できることです。

91

1 つの戦略として、オンデマンドインスタンス の コアグループを起動して、

アプリケーション の コンピューティングリソースの最低保証レベルを維持し、

機会が発生したときに スポットインスタンス で オンデマンドインスタンスを

補完する方法があります。

92

93

94

95

96

97

98

99

ロングポーリング

アプリケーションの ポーリングモデル を設計する際、トレードオフを行う必要が

あります。

エンドトゥーエンド の スループットをできる限り高く維持するために、できる限り

ポーリングしたいと考えるでしょうが、 ポーリングの間隔が短くなれば、

CPUサイクルが燃えさかり、高くつきます。

100

新しいロングポーリングモデル を使えばこの難しいトレードオフをする必要が

なくなります。

メッセージが利用可能になるまで、1から20秒待つ単一のReceiveMessage

コールを作成できます。

メッセージはできる限りすぐに送られますので、メッセージが利用可能で

ある際、遅延はありません。

101

重要な副作用として、ロングポーリングは メッセージのための全てのSQSホストを

チェックします ( 定期的なポーリングがサブセットをチェックします ) 。

ロングポーリングが空のメッセージセットを返すことにより、未処理のメッセージが

キューに存在しないことが確認できます。

102

ReceiveMessage をコールする際、WaitTimeSecondsパラメータを0

(ゼロ)以外の値にセットすることにより、コール毎にロングポーリングを

利用することができます。

SetQueueAttributes関数を使って0(ゼロ)以外の値を対応するキューの

属性にセットすることもできます。

103

すると、そのキュー上のそれ以降全てのReceiveMessageのデフォルトに

なります。また、AWS Management Console からもセットすることが

できます。

104

105

106

Delay Queue 遅延キュー

遅延キューを使用すると、キューにある新しいメッセージの配信を一定の

秒数延期することができます。

遅延キューを作成した場合、そのキューに送信したすべてのメッセージが

遅延期間の間 コンシューマーに表示されなくなります。

107

DelaySeconds 属性を 0 ~ 900(15 分)の任意の値に設定することで、

CreateQueue を使用して遅延キューを作成できます。

SetQueueAttributes を使用してキューの DelaySeconds 属性を設定する

ことにより、既存のキューを遅延キューに入れることもできます。

遅延キューは、メッセージを一定の時間コンシューマーが使用できなくする

という点で可視性タイムアウトと似ています。

108

遅延キューと可視性タイムアウトの違いは、遅延キューの場合、メッセージが

最初にキューに追加されたときに非表示になるのに対して、可視性タイム

アウトの場合、メッセージがキューから取得された後のみ非表示になる

という点です。

次のスライドの図は、遅延キューと可視性タイムアウトの関係を示しています。

109

110

111

112

Dead Letter Queue デッドレターキュー

Amazon SQS では、デッドレターキューがサポートされるようになりました。

デッドレターキューは、何らかの理由で正常に処理できなかったメッセージの

送信先として他の(送信元)キューが使用できるキューです。

113

デッドレターキューを使用することの主なメリットは、正常に処理されなかった

メッセージを対象から外して隔離することができることです。

その後、デッドレターキューに送信されたメッセージを分析して試行し、正常に

処理されなかった理由を調べることができます。

114

デッドレターキューを指定するには、AWS マネジメントコンソールまたは

クエリ API を使用します。

これは、デッドレターキューにメッセージを送信する各(送信元)キューに

対して行う必要があります。

1 つのデッドレターキューを複数の(送信元)キューの送信先とすることが

できます。

115

116

117

AWS Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、

Go および Docker を使用して開発されたウェブアプリケーションやサービスを、

Apache、Nginx、Passenger、IIS など使い慣れたサーバーで デプロイおよび

スケーリングするための、使いやすいサービスです。

118

ユーザーはコードをアップロードするだけで、Elastic Beanstalk が、

キャパシティのプロビジョニング、ロードバランシング、Auto Scaling から

アプリケーションの状態モニタリングまで、デプロイを自動的に処理します。

同時に、ユーザーのアプリケーションが稼動している AWS リソースの完全な

コントロールを維持でき、いつでも基本的なリソースにアクセスすることが

できます。

119

120

AWS Elastic Beanstalk

AWS Elastic Beanstalk は、AWS クラウド内でのアプリケーションの

デプロイと管理をさらに簡単にするサービスです。

開発者は単にそのアプリケーションをアップロードするだけで、

Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、

Auto-Scaling、およびアプリケーション状態モニタリングといったデプロイの

詳細を処理します。

121

AWS Elastic Beanstalk を使用するのは、アプリケーションを短時間で

AWS クラウド内にデプロイして管理したいという方です。

クラウドコンピューティングの経験がなくても開始できます。

AWS Elastic Beanstalk では Java、.NET、PHP、Node.js、Python、Ruby、

Go、Docker のウェブアプリケーションがサポートされます。

122

次のスライドの図は、ウェブサーバー環境枠の Elastic Beanstalk

アーキテクチャの例と、このタイプの環境枠のコンポーネントがどのように

連係するかを示しています。

環境はアプリケーションの中心です。 次のスライドの図では、環境は青い

実線で示されています。

123

環境を作成するときは、アプリケーションを実行するのに必要なリソースを

Elastic Beanstalk がプロビジョニングします。

環境用に作成された AWS リソースには、1 つの Elastic Load Balancing

(図では ELB)、Auto Scaling グループ、および 1 つ以上の Amazon

EC2 インスタンスがあります。

124

125

CloudFormationでElastic Beanstalkでアプリケーションとその依存関係のモデル化した例

126

127

AWS Identity and Access Management (IAM)

AWSアカウントに 子アカウントを作成し、必要な権限を割り当てる機能です。

この機能を利用することにより 、必要なユーザー に対して 最低限の管理画面・APIアクセスを 許可できるようになります。

企業の業務用途で AWSを利用する場合、ほぼ必須の機能と言えます。

設定によって MFA (多要素認証)といって、 ID・パスワードの組み合わせだけで

なく、モバイルデバイスや 専用のハードゥエアによって生成された番号を

入力しなければログインできないようにするなど、より高いセキユリティレベルにすることもできます。

128

129

Amazon CloudWatch

Amazon CloudWatch は、AWS クラウドリソースと AWS で実行する

アプリケーションのモニタリングサービスです。

Amazon CloudWatch を使用して、メトリックスを収集して追跡すること、

ログファイルを収集してモニタリングすること、アラームを設定すること、

および AWS リソースの変更に自動的に反応することができます。

130

Amazon CloudWatch は、Amazon EC2 インスタンス、Amazon

DynamoDB テーブル、Amazon RDS DB インスタンスなどの

AWS リソース、およびアプリケーションやサービスに生成された

カスタムメトリックス、およびアプリケーションが生成するあらゆる

ログファイルをモニタリングできます。

131

132

133

Amazon Simple Notification Service (Amazon SNS)

Amazon Simple Notification Service(Amazon SNS)は、クラウドからの

メッセージ通知のセットアップ、作業、送信を簡単にするウェブサービスです。

アプリケーションからメッセージを発行し、登録者や他のアプリケーションに

迅速に配信するための、スケーラブルかつ柔軟で、費用対効果の高い機能を

備えています。

134

また、ウェブスケールの コンピューティングを開発者が簡単に利用できるよう

設計されています。

Amazon SNS は、「publish-subscribe」(pub-sub)メッセージング

パラダイムに従っています。

ここでは 「プッシュ」 メカニズムを用いて通知が配信されるため、新しい情報や

更新のために定期的に確認または「ポーリング」を行う必要がありません。

135

Amazon SNS サービスでは、アプリケーション、ワークフローシステム、

タイミングの重要な情報更新、モバイルアプリケーション、そして通知を

必要とするその他あらゆるアプリケーションのモニタリングなど、幅広く

多様なニーズがサポートされます。

例えばAmazon SNS は、分散型コンピューターアプリケーション間で

イベントを中継、データストア間でデータを移動、またはビジネスシステム

内の記録を更新するための ワークフローシステムで使用することができます。

136

検証、承認、在庫変更、発送ステータスに関するイベント更新と通知は、

エンドユーザーだけでなく、関連するシステムコンポーネントにも直ちに

配信されます。

Amazon SNS の別の使用例は、タイミングの重要なイベントをモバイル

アプリケーションやデバイスにリレーすることです。Amazon SNS は

信頼性が高くスケーラブルなため、リアルタイムイベントが欠かせない

アプリケーションを開発する開発者にとって、これが大きな利点となっています。

137

138

139

140

141

142

メッセージを発行してカスタマーが通知を受信できるようになるためには、

特定のサブジェクトや イベントタイプを確認する アクセスポイントとなるトピックを、

開発者が最初に作成する必要があります。

一旦トピックが作成されると、トピックの所有者はそのポリシーを設定する

ことができます。

143

これには例えば、メッセージの発行者または通知の受信者を制限したり、

どの通知プロトコルがサポートされるのか (例: HTTP/HTTPS、Eメール、

SMS) を指定したりすることが挙げられます。

受信者 (サブスクライバー)は、興味を抱くトピックから通知を受け取ることに

関心があるカスタマーです。

144

彼ら、またはトピックの所有者がトピックを受信できます。受信者はプロトコルと

エンドポイント(URL、Eメールアドレス等)を通知を受け取るために指定します。

発行者が受信者に通知すべき情報または更新情報を保有している場合、

彼らはトピックに対するメッセージを発行できます。

これによって Amazon SNS から、該当する全受信者に対して直ちに

メッセージが配信されます。

145

Amazon Simple Queue Service(SQS)および Amazon SNS は共に

AWS 内のメッセージングサービスですが、開発者にそれぞれ異なった

利点を提供します。

① Amazon SNS を利用すれば、アプリケーションは「プッシュ」メカニズムを

使用して、複数の受信者にタイミングが重要なメッセージを送信することが

できます。

そのため更新を定期的に確認または「ポーリング」する必要性がなくなります。

146

② Amazon SQS は、分散型アプリケーションが使用するメッセージ

キューサービスであり、ポーリングモデルを通じてメッセージを交換し、

コンポーネントの送受信を切り離すために使用することができます。

Amazon SQS ではアプリケーションの分散型コンポーネントに対して

柔軟性が提供され、同時に利用可能な各コンポーネントを必要とする

ことなくメッセージの送受信を行うことができます。

147

148

149

補足: Amazon CloudWatchでの Billing Alertの通知

アラートと通知で請求額をモニタリング

CloudWatch を使用して AWS のコストをモニタリングできます。

CloudWatch を使用すると、サービスの使用量が定義済みのしきい値を

超えた場合に通知する、請求アラートを作成できます。

150

請求アラートを作成するしきい値の使用量を指定します。

使用量がこれらのしきい値を超えた場合、AWS から E メール通知が

送信されます。

AWS の料金変更に伴って通知を受け取るよう登録することもできます。

請求アラートを作成し、通知を受け取るための登録を行うには、まず次の

手順を使用して、Billing and Cost Management コンソールでこれらを

有効にする必要があります。

151

152

補足: Amazon Simple Email Service (Amazon SES)

Amazon Simple Email Service (Amazon SES) は、企業や開発者のための、

非常にスケーラブルで、コスト効率のよい E メールサービスです。

Amazon SES により、社内でEメールソリューションを構築したり、こうした種類の

EメールコミュニケーションのサードパーティのEメールサービスをライセンス、

インストール、または操作したりする複雑性とコストを排除できます。

153

加えて、このサービスは他の AWS のサービスと統合されているため、AWS で

ホストされているアプリケーションから 簡単にEメールを送信することができます。

154

155

156

157

補足: Amazon Elastic Transcoder

Amazon Elastic Transcoder は、開発者や企業が動画および音声

ファイルをスマートフォン、タブレット、PC などのデバイスで再生可能な

バージョンに変換(「トランスコード」)することができる、非常にスケーラブルで、

使いやすく、費用対効果が高いサービスです。

158

幅広い入力および出力フォーマット、解像度、ビットレート、およびフレーム

レートに対応するほか、Amazon Elastic Transcoder には、

動画ビットレートの自動最適化、サムネイルの生成、ビジュアル

ウォーターマークのオーバーレイ、キャプションのサポート、

DRM パッケージ、プログレッシブダウンロード、暗号化などの機能も

用意されています。

Amazon Elastic Transcoder を使用すると、動画および音声ファイルを、

デスクトップ、モバイルデバイス、タブレット、およびテレビでの再生に

最適化された、サポートされる出力フォーマットに変換できます。

159

160

161

162

163

164

165

166

167

参考文献:

Amazon.com, Inc.社 公開資料

168

本資料の関連資料は下記をクリックして

PDF一覧からお入り下さい。

ITライブラリー (pdf 100冊)http://itlib1.sakura.ne.jp/

目次番号 453番 AWS詳細解説 全33冊 計6,100ページ

169