そのアクセス権を変更できます。アカウントを簡単に管理できます。アカウントを組織単位にグループ化し、アプリケーション、環境、チーム、その他ビジネスにとって意味のあるグループ毎に、アカウントを管理できるようになります。複数のアカウントに一度にポリシーを適用できる機能を提供します。プレビューに今すぐ登録してください。参加することもできます。AWSAWSソリューションアーキテクトの篠原英治(@shinodogg)です。5thに参加してきました。Seminar「製造業でのAWS利用事例のご紹介」の資料およびQA公開みなさん、こんばんは。連投でご紹介となりますが、12/13に開催したBlackBeltオンラインセミナー「製造業でのAWS利用事例のご紹介」の公開資料と、QA回答を紹介させて頂きます。製造業の中でも、基幹系、R&Dなど、さまざまなITインフラとして活用されているAWSの事例を網羅的に紹介した内容となっております。Japan【Q&A】Q1:どのようにして製造業のお客様へAWSを提案していくか、または、許容される提案をするかという所で、「在庫とお客様への提供スピード」という例がありましたが、可能であればもっと詳しくお聞かせ願います。A1:ご紹介した事例の多くは実際にお客様にお話し頂いている動画を公開しております。紹介スライドの下部にあるURLからアクセス頂き、動画の方でご確認下さい。https://www.youtube.com/watch?v=RB2ATTfdKcoQ2:AWSの費用は、例えば事業部ごとに分ける事は可能でしょうか?A2:はい。事業部単位でAWSアカウントを取得して頂き、支払いを1つのアカウントに集約することが可能です。https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/consolidated-billing.htmlまた、下記の資料もあわせてご参考にして頂ければと思います。QuickSight」の資料およびQA公開こんばんは、ソリューションアーキテクト小川です。QuickSight」でした。資料も公開されておりますので、当日ご参加の皆様から頂戴したQAの回答も併せて紹介させて頂きます。Japan【Q&A】Q1:大規模データの保存にはS3を使う事が一般的との事でしたが、どのような理由からでしょうか?DynamoDBとの比較で教えて下さい。A1:DynamoDBも大量のデータを高い耐久性で保存できるため、データの保存場所として使っていただく事は可能です。DynamoDBはNoSQL型のデータベースですので、S3のように任意のファイルが保存できるような仕組みでは無いという点に注意が必要です。Key-Attributesの形でデータを保存し、そのAttributeで検索をしたいというニーズにはDynamoDBがフィットしますし、多様なデータ・フォーマットのファイルを保存するにはS3が適しています。Q2:S3にgzip圧縮したcsvファイルをデータソースとして扱えますか?A2:SPICEにGZIP圧縮のデータを取り込むことが可能です。Q3:DynamoとかnoSQL系のDBに蓄積しているデータをQuickSightで利用することはできないんですか?A3:現時点ではDynamoDBへの接続はサポートされていませんが、ホームページにも記載がありますように、将来的なリリースでDynamoDBへの接続をサポートする予定です(予定は予告なく変更される可能性があります)。Q4:QuickSightとデータソースのリージョンは統一する必要がありますか?A4:技術的には同じリージョンでなくても利用は可能です。QuickSightからはTCP/IP接続可能なグローバルIPアドレスを持っているリソースに接続が可能だからです。大量のデータ転送にかかる時間や、データ転送に掛かる費用を考えるとできるだけ同一リージョン、もしくはデータソースに近いリージョンで御利用いただくのが良いと考えられます。Q5:デモサンプルが触れるサイトは提供していますか?A5:サインアップしていただくと、自動的にサンプルデータが用意されるようになっています。無料枠もありますので、ぜひお試しください。RDSのデータに接続する際に、個人情報など特定の項目を取り込まない、あるいはハッシュ等で暗号化することは可能でしょうか?A6:どのデータを取り込むかは、Prepareフェーズで設定が可能であり、特定の列を取り込まない形でデータソースを定義することで、ご質問のようなニーズに対応できると考えられます。Prepareでのハッシュ変換は対応していませんが、カスタムSQLを使ってデータソースの定義が可能なため、SQLで表現可能な変換であればデータの加工が可能です。Q7:SPICEを利用した場合の自動リフレシュは可能ですか?A7:現時点では自動リフレッシュの機能は無いため、手動でリフレッシュしていただく必要があります。ご要望はサービスチームにフィードバックさせていただきます。RDSとSalesforceのデータを結合してQuickSightに取り込むことは可能でしょうか?A8:現時点では、データソースをまたがった形でデータをジョインしたり、Visual内で混ぜて使うことはできません。事前にRDS、もしくはSalesForceどちらかに必要なデータを取り込んでおく必要があります。Q9:データソース:RDSの場合、RDSがupdateした場合、再度spiceに取り込む必要がありますでしょうか?A9:現時点では自動的にSPICEへ反映(リフレッシュ)されませんので、手動でリフレッシュしていただく必要があります。Q10:カスタムSQLで書けるSQLはデータソースのRDBMS依存との認識で良いでしょうか?A10:カスタムSQLは直接データソースのRDBMSに投入されますので、データソースのRDBMSに依存します。Q11:誰でも見れるようなグラフを作りたい場合、ユーザはどのような設定になりますでしょうか?A11:現時点では、QuickSIghtで作成したデータを閲覧するには、QuickSight上でサインアップ(サブスクリプション)したユーザが必要になります。Q12:グラフをAPIなどで取得してカスタムなサイト上に表示して使うことは可能でしょうか?A12:現時点ではQuickSightにアクセスするためのAPIは用意されていませんので、ご質問のような操作はできません。APIについては今後のリリースで追加されることが予定されているため、そこで該当するようなAPIがリリースされれば出来るようになる可能性があります。(予定は予告なく変更される場合があります)Q13:データベースの公開IPアドレス範囲が、QuickSightサービス以外の第三者に使用されることはありますか?A13:第三者(AWS以外)に利用されることはありません。この公開IPアドレスのレンジは今後変更される可能性もある点にご注意ください。Q14:ダッシュボードをWebページに埋め込むことは可能でしょうか?A14:現時点ではWebページへの埋め込みには対応していません。いただいたご要望はサービスチームにフィードバックさせていただきます。Q15:複数の違う会社へ別々のviewを見せる時はどのようにすればよろしいでしょうか?どちらも会社固有の情報で他の会社様へ見せないようにしなければなりません。A15:QuickSightでVisualやダッシュボードを共有する場合、管理者からinviteされ、QuickSightにサインアップしている必要があります。(QuickSightのアカウント無しに閲覧させることはできません)ダッシュボードは複数作成することができ、それぞれ別のユーザにシェアすることが可能です。Q16:SPICEにアップできるファイルサイズは10GBということですが、ユーザーが2ユーザーの場合、20GBアップできますか?A16:ユーザ数を増やすことでSPICEのデータ領域の総量は増加しますが、1つのデータセットにおけるサイズ制限は変わりません。2ユーザであっても、SPICE上の1つのデータセットは10GBまでです。BlackBeltオンラインセミナーを予定しております。みなさまご参加下さい。パート2」の資料およびQA公開ソリューションアーキテクトの小川です。Greengrass・エンタープライズアプリケーションといった新機能や新サービスについてSA舘岡&松久より解説させて頂きました。下記に当日の資料とQAをご紹介させて頂きます。Japan【Q&A】Q1:障害と予定された変更以外というのは、どんな事象がありますか。A1:現状は提供できる情報はないのですが、今後のアップデートで様々な情報が取得出来るようになると思いますのでご期待ください。Q2:workspacesで古いofficeを使うことはできますか?アンインストールして別バージョンを入れることが可能か。ECSチームから発表しました。これによって、ECS上にカスタムスケジューラや他のツールを開発することができます。Bloxの目標は、カスタムスケジューラ、ダッシュボード、その他の拡張を作ることをシンプルにするためのツールを提供することで、皆さんの特定のユースケースの要件に合わせることができます。ECSは先日、イベントストリームが利用可能になったこともアナウンスしており、これによってECSコンテナインスタンスとタスクの状態変化が[cloudwatch_events]に送られます。スケジュールワークフローを開発するお客様はしばしばECSクラスタで生成されたイベントを受け取り、この状態を手元に保存して、ローカルのクラスタの状態を使って操作を行います。APIで提供するcluster-state-serviceが含まれます。BloxはECSクラスタの現在のリソース状況を必要とするカスタムスケジューラや処理を開発したり、クラスタのイベントに応じてアクションをしたい開発者をターゲットとしています。Bloxは、ECSクラスタ上のすべてのコンテナインスタンスにおいてそれぞれ1つだけのタスクを起動できるdaemon-schedulerも含まれています。このスケジューラは新しいコンテナインスタンスがクラスタの参加したかを監視していて、そこにタスクを配置します。Bloxのdaemon-schedulerによって、ログエージェントやメトリクス収集エージェントの様なタスクをECSクラスタ上で起動できるようになります。私達はBloxをオープンソースソフトウェアとしてリリースできて大変うれしく思っており、ECSの周辺ツールのエコシステムを開発していく計画があります。Bloxを使ったり貢献したりすることに興味があれば、BloxのGitHubレポジトリをご覧ください。機能要望の数を見続けていて、ロードマップのために評価しています。GitHubのレポジトリに参加して、改善点の発見や優先度づけにご協力下さい。Bloxをデプロイするローカル環境にBloxをデプロイするBloxをとりあえず初めてみたい方には、ローカルのDocker環境にフレームワークをデプロイすることをお勧めします。Composeファイルを提供しています。これによって、cluster-state-serviceを使ったカスタムスケジューラの開発を始めることができます。Eventsで送られるECSイベントストリームに依存しています。Bloxを使うためには、SQSキューを作成し、ECSイベントがこのSQSキューに送られる様にCloudWatchを設定する必要があります。CloudFormationテンプレートを提供していて、必要なAWSのコンポーネントをデプロイし設定することができます。EventsとSQSキューの設定が終わり、Bloxをデプロイする準備が整います。Composeファイルをダウンロードします。Bloxを起動する前に、先に以下の様にdocker-compose.ymlを更新する必要があります:AWS_REGIONの値を、ECSとSQSのリソースがあるリージョンに更新しますAWS_PROFILEの値を、~/.aws/credentials内のプロファイルの名前に更新します。defaultプロファイルを使っているなら、このステップは省略可能です。3000/tcpこれでBloxのローカルインストールは完了です。APIを利用開始できます。daemon-schedulerを使うdaemon-schedulerは以下のコンセプトを持っています:environmentは、管理されるタスクの希望の状態設定を表しています。daemon-schedulerでは、指定のクラスタに起動したいタスク定義のことを指します。deploymentは、environmentを実際に実現する操作のことです。このスケジューラでのdeploymentとは、environmentにある希望の設定状態をそのクラスタに実現させることを指します。Clusterのガイドに従って下さい。タスク定義の登録ECSクラスタにタスクを起動するためには、ECSにタスク定義を登録する必要があります。なければ、以下のタスク定義を使うことができます。file:///tmp/nginx.jsonnginxタスク定義のARNを調べておきます。次のステップで必要になります。]}daemon-schedulerを使ってデーモンのワークロードを起動この例では、Bloxが提供するスケジューラとのやりとりのためのdemo-cliを使っています。daemon-schedulerのAPIの説明はBloxのGitHubレポジトリをご覧ください。]}environmentの作成に成功すると、daemon-schedulerのレスポンスの中には次のステップで使われるdeploymentTokenが含まれます。--deploymentTokendeploymentを作成することで、スケジューラはenvironmentに設定されたタスク定義をクラスタ内のすべてのコンテナインスタンスに起動します。したら、ECSコンソールに行って、コンテナインスタンス上で実行されているタスクを確認することができます。これで、daemon-schedulerを使って無事にECSクラスタにデーモンのワークロードを起動することができました。AWSにBloxをデプロイするBloxはAWS上にもデプロイ可能です。Gatewayが作られ、認証機構を提供します。GatewayのエンドポイントからリクエストをVPC内のALBのリスナーに転送しています。このBloxのデプロイをすることで、アカウントに紐付いているECSクラスタの管理に使うことができます。このオプションでの設定方法については、GitHubレポジトリの説明をご覧ください。今から利用可能ですBloxは本日から利用可能です。詳細は、GitHubレポジトリ内のドキュメントをご覧下さい。チームのシニアデータベースエンジニアです。Redshift環境のパフォーマンスを更に引き出すための2つのシンプルなテーブルデータの永続性に関するプロパティの使い方について説明します。S3にプッシュします。これらの自動バックアップは時間の閾値または変更されたブロックによりトリガーされます。このアプローチによりスナップショットやテーブルレベルのリストア操作などのリカバリ機能が可能となっています。一般的に自動バックアップの実際の処理コストは大きなものではありません。データブロックをS3に転送するため、継続的に大規模なCOPYやUNLOADを実行するワークロードに関するS3へのスループットに影響を与える可能性があります。NO」テーブルプロパティを使用することができます。TEMPORARYとして定義されたテーブル(一時テーブル)は、それらが作成されたセッションの終了時にクリーンアップされるため、デフォルトでこのプロパティを継承しています。Redshiftは自動的にクラスタ内の別ノードが持つテーブルデータの冗長コピーを保持するため、複数のディスクやノードの障害に耐性を持ちます。全ての同期データレプリケーションと同様に、このプロセスにはオーバーヘッドがあります。一時テーブルに関しては、システムがそれらのテーブル内のデータは一時的なものであると見なしているため、レプリケーションは実行されません。一時テーブル内のブロックは自動バックアップをトリガーする閾値にはカウントされません。NOオプションを使用した場合と同様に、バックアッププロセスの起動を回避し自動バックアップが完了するまでの速度を向上することができます。一時テーブルのデータはレプリケートされていないので、一時テーブルデータをコミットするトランザクションは永続テーブルに対して実行するよりも処理コストが低くなります。適切な場面で一時テーブルを活用することで、クラスタのオーバーヘッドを大幅に抑制することができると言えます。例として、テーブルデータが単一のセッション内でのみアクセス可能であればよい場合や、本質的に一時的なデータである場合が挙げられます。下記のクエリを使用して、クラスタ内でこれらのテーブルプロパティのいずれかが適用されているテーブルを特定することができます。1;次のステップあなたの環境のデータの永続性や保存の要件次第では、これらのオプションを使用することは適切ではないかもしれませんが、それでも問題ありません。このブログシリーズを通して説明してきた内容の中では、今回のような細部の最適化はクラスタ全体のパフォーマンス向上への貢献度は小さいかもしれません。上から下まで最適化されている環境においては、これがパフォーマンス向上のために紹介できる最後のテーブルデザインコンセプトとなります。Redshiftのユーザーが最適なパフォーマンスを得るためのワークロードをチューニングすることを支援しています。Redshiftサービスチームの一員として、彼は新しいサービスや既存のサービスの開発にも影響を与えており、貢献しています。休暇の際は妻のメアリーと一緒に新しいレストランにトライし、生まれたばかりの娘ソフィアの世話を楽しんでいます。※日本語訳はSA岡本が担当しました。Facebookこのブログの最新情報はTwitter、Facebookでもお知らせしています。お気軽にフォローください。