AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - すべて

1 / 2212345...1020...最後 »

[AWS]Athenaについて(その1 概要編)

2018.07.20

AWSのコンソールにログインして、サービスの一覧を見るたびに


「もはや知らないお友達の方が多いんじゃないか」と思うpinocoですこんにちは。


今日はその知らないお友達リストの中から、


「随分前から名前は知っているぞ」「興味もありそうだぞ」


というAthenaについて全何回になるかわかりませんが、お送りしたいと思います。


 


 1. 執筆前のAthena(アテナ)に関する精一杯の知識


色々なエンジニアさんが書く、「初めて触る技術についてのブログ」


なんかを読んでいて、個人的に結構気になる点として、


 * だいたいどれくらいの知識レベルの時点で執筆を開始してるのか?


    * 執筆後だいたいどのくらい理解している状態になっているか?


があげられます。


つまり、どの程度の前提知識を有していれば、


そのブログなり記事なりの筆者が伝えたいと思ったことを追体験できるのか、


もう少し知識をつけて出直すべきなのか?とか考えたりします。


なので、参考になるかはわかりませんが、


先にAthenaに対する私の現段階の理解や知っていることを開示しておきます。


(1). 聖闘士星矢に出てきた(と思う)


(2). GodOfWarに出てきてクレイトスを裏切った(と思う)


(3). S3にputしたファイルに対しQuery実行ができる(と聞いた気がする)


もはや何も知らなかった方がよかったんではないかと思う惨状を呈したところで


では早速始めましょう。


 


2. Athenaとは


よくわかりません。失礼致します。


ということで、よくわかってないサービスを触る時に私がとるアプローチは以下が多いです。


* slideshareでAWSの方が上げているその時一番読みやすくかつ、


 最新と思われる、該当サービスの資料(BlackBelt)を読む


 ※今回だとAmazon Athena 初心者向けハンズオンが自分には合っていたかもしれません。


* 上記と並行して公式ドキュメントで肉付けを行う


* ある程度輪郭が掴めたら実際に触ってみる


今回もそのアプローチに則ってやってみたいと思います。


 


2-1. Athenaの特徴


まずは、サービスの大きな特徴やポイントぽいものをメモを取りながら、


ざっくりと抑えていきます。


(1). S3上のデータ(ファイル)に対し、ANSI 標準SQLを利用できる


(2). データ(ファイル)に利用できる拡張子→サポートされる SerDes およびデータ形式(公式)


(3). クエリエンジンとしてPrestoを利用(この子が標準SQLを使えるようにラップしてくれてる)


(4). データ処理はオンメモリで行われる


(5). (4)よりS3上のデータ(ファイル)を読み込まないと始まらない


(6). (5).より読み込むデータ(ファイル)の量が多くなればなるほど問題が出そう


  * 処理データ増大→レスポンス遅延、メモリ枯渇


(7). (6).への対処として、


        * Athenaが読み込む領域をパーティションで分割する、


  * inputするファイルとして列指向、圧縮形式を採用するなんていうアプローチがある


     * 実質、設計する部分としてはこの辺な気がするので、続編で掘り下げる。


(8). 料金は「クエリごとにスキャンされたデータ量」で算出される。


  * スキャンされたデータ 1 TB あたり 5 USD(2018/07/20 時点)


   * 1TB = 5USDで0.5TB=2.5USDとなる


  * S3に置いてあるデータは、S3の料金体系に準拠。


ここまでを振り返ると、


  * Athenaでクエリ発行時に読み込むデータ量を減らすアプローチが、


  なんとなく性能的にも、お財布的にも優しそうである


ということがぼんやりわかりました。


まずはこのくらいで機能周りの把握は止めておいて、


あとで検証するときにより細部の知識を積んでいく形にします。


では次は観点を変えて、相性のいいサービスやユースケースを整理してみます。


 


2-2. Athenaを利用した構成、ユースケース


実際に触る前に、もう少しだけ抽象度が高い部分で情報を整理しておきます。


いざAthenaを使おう!となった場合、どういう風に使うのが誰(何)にとってどう便利なのか?的なことを


ほんのり意識してるといいかもしれません。ちなみに私はそういうことはできないです。


 


(1). 実際にクライアント側からAthenaを利用するパターン


* ODBC / JDBCでの接続


  * AWS APIを介した接続ではないため、


     AthenaはODBC / JDBCに対応した独立したデータソースとして振る舞う


  * SQL WorkBench等クライアントツールでの接続や、


   各ドライバを利用したアプリケーションでの利用ができる


  * AWS APIを介していないため、


    別のところで認証・認可を管理していると思うけれど、


    その部分については不明瞭。ユーザやスキーマ周りについてどういう扱いになるのか


    後続で整理が必要。


 


  * AWS Management Consoleからの利用、AWS CLIからのクエリ発行も可能。


  * AWS CLIからクエリの実行ができると、


    バッチやスクリプト組むときの選択肢が広がるのはわかるのですが、


    ODBC/JDBC対応しているという前段があるので


  「RDSにクエリ投げられるAWS CLI(API)あります!」みたいなことを言われた感じに思えて


    少しだけ違和感を覚えました。


    例えばBigQueryとかはAPIでクエリ投げますけど、ODBC/JDBCには対応してないですよね。


    こういうのって、そもそもサービスの思想が違うだけなんですかね。難しい。


 


  * AWS QuickSightを利用したアクセス


  * BIツール。Athenaに接続して利用することができる。


  * ちなみに、TableuもAtheneに対応している様子


           * 分かってないことが芋づる式に増えていきますね。


 


(2). AWS Glueを介在させる


        * これはGlueというサービスを別途整理しないとかけそうにないです。


   自身の理解が追いつくまでに時間を使いそうなので整理後Uodateかけておきます。


 


と、ここまでで、第一回は終わりにしたいと思います。


結局 Athenaに触ってもいませんね。触れるのは、いつになるやら。。


 


次回は


・Athenaでクエリ発行時に読み込むデータ量を減らすアプローチを整理してみる


を中心に深掘りしていきたいと思います。


 


以上、よろしくお願いいたします。

[GCP] Speech-to-text APIについて

2018.07.18

大変お世話になっております。pinocoです。


弊社は「AWSでなんか、なんか、こう、頑張っていこう」的な感じの会社なのですが、


今日はGCPのサービスについて書いてみたいと思います。


ちなみに余談なのですが、


2018の1Qの各クラウドサービスのシェアはAmazon,MS,IBMと来て第4位にGoogleでございました。


私の肌感覚ではAmazon(AWS),Google(GCP)が主なので「そうなのかー」と感慨深い感じの結果でございました。


もうちょっとAzureやSofLayerなんかも勉強しないといかんなあ、と感じるところではあります。


 


では本題。


今回検証したのはGCPのCloud Speech to Text APIでございます。


どんなものか、ものすごく掻い摘んで説明しますと、


「音声をinputとしてその音声をテキスト化したものをOutとして返してくれる」


そんなAPIでございます。


では触っていきましょう。


1.inputファイルの作成


音声ファイルの作成については、オフィスで一人ブツブツいいながらつくる勇気がなかったので


とりあえず、弊社の社是ぽい文言をテキスト化してそれをmacのsayコマンドで読み込ませて作ります。


人が読むよりも精度として得られる結果が高くなりそうな気がしますが、羞恥心には変えられませぬ。


# sayに渡すファイルを作る
cat << _EOS_ > ./input.f
選ばれ続ける
社会・お客様・従業員にとって無くてならない企業として、
100年後も必要とされていること。
そのためにIT技術を手段として、様々な課題を解決します。
解決するためのプロセスは、可能なかぎりシンプルに。
より少なく、よりシンプルに、そしてより良く。
シンプルであることで本質に近づくと考えています。
_EOS_


# 作ったファイルをsayコマンドに与えて,wav形式のファイル(リニアPCM,16bit,1600Hz)を作ります
say -o simp.wav --data-format=LEI16@16000 -f ./input.f

ちなみにさらっと書きましたが、APIが対応している音声ファイル形式に合わせるのに苦心しました。


ここまできたら次はGCP側で作業をします。


2. GCPでやること


基本的にはGCPで公開されているのQuickStart(Using the Command Line)に従って


進めて行けばいいだろう、と「だろう運転」で進めたところ


全然QuickにStartを切れなかったため、以下でやった事を整理しつつ


理解を深めたいと思います。


 


QuickStartの「Speech-to-Text API を有効にする」に従い、Speech APIを有効化します



 


で権限を紐づけるサービスアカウントの


役割に「GCSのオブジェクトへの閲覧権限」をつけています。


※APIを呼んでも肝心のGCSに配置した音声ファイルが見れない、という事態がこれで防げるはずです。


 


 


上記まで完了したら認証情報(json)が取得出来ますので大事に取っておきます。


 


APIの有効化が済んだら、GCS上にRegional/ASIA-NORTHEAST1でGCSにバケットを作成して、


作成した音声ファイルをputしておきます。


 



 


3. クライアント側での認証情報の設定と、APIの実行


 


GCPの認証情報を処理するため、google cloud SDKを投入しておきます。


で以下の通りSpeech APIの権限と紐付けてあるサービスアカウントのjson読み込ませ、


アクセストークンが取得できる状態にしておきます。


# サービスアカウントの認証情報の読み込み
gcloud auth activate-service-account サービスアカウントのアドレス --key-file APIの有効化の時に取得した.jsonのフルパス
# サービスアカウントのトークン取得
gcloud auth print-access-token サービスアカウントのアドレス


# 補足
# 確認
gcloud auth list
# 検証後、利用した認証情報を除去する
gcloud auth revoke サービスアカウントのアドレス

API実行時にパラメーターを渡すためのjsonファイルを作っておきます。


 


cat << _EOS_ > param.json
{
"config": {
"encoding": "LINEAR16",
"sampleRateHertz": 16000,
"languageCode": "ja-JP"
},
"audio": {
"uri": "gs://バケット名/simp.wav"
}
}
_EOS_

ではトライします。


work$curl -s -H "Content-Type: application/json" \
> -H "Authorization: Bearer "$(gcloud auth print-access-token サービスアカウントのアドレス) \
> https://speech.googleapis.com/v1/speech:recognize \
> -d @param.json
{
"error": {
"code": 403,
"message": "The caller does not have permission",
"status": "PERMISSION_DENIED"
}
}
work$

はい、失敗です。「権限がない」と怒れらます。


もう何も信じられません。


とりあえずダメもとでGCSの音声ファイルオブジェクトのプロパティから


サービスアカウントに対して「読み取り」権限を振ってあげます。


で再度トライ。


work$curl -s -H "Content-Type: application/json" \
> -H "Authorization: Bearer "$(gcloud auth print-access-token サービスアカウントのアドレス) \
> https://speech.googleapis.com/v1/speech:recognize \
> -d @param.json
{
"results": [
{
"alternatives": [
{
"transcript": "選ばれ続ける社会お客様従業員にとってなくてならない企業として100年後も必要とされていることそのために言っと技術を手段として様々な課題を解決します解決するためのプロセスは可能な限りシンプルにより少なくよりシンプルにそしてより良くシンプルであることで本質に近づくと考えています",
"confidence": 0.94387203
}
]
}
]
}
work$

うまくいきました。


confidenceが0.94(おそらく信頼度が94%とかってことだと思われます)です。


 


でも、なぜうまく行ったのでしょうか。


サービスアカウント作成するときに「ストレージオブジェクト閲覧者」をつけたのに。。


それでは駄目だったということは結果から推察できるのですが、


ではどうすべきだったかが?すぐにはわからないです。


これは宿題にしておきます。


 


私のGCP,IAMに関する圧倒的な理解度の低さを見せつけたところで、


今日はこれまでにしておきます。


 

CloudFormationを弄ってみるお話

2017.11.22

・はじめに


 私はAWSを資格取得のために勉強はしたが、AWSを弄ったことはほとんどない。だが研修でWSFCをAWS上で構成するに当たり、複数台を同じ構成で作る必要があった。意外と一つ一つ設定して立ち上げてが面倒くさい。これを簡略化できないかと考えたところで、そういえば先日合格したAWS SAAの試験でCloudFormationというものが出てきたということを思い出した。これはどこまで構築してくれるのか。

 典型的な頭でっかちを脱却すべく、各AWSサービスを弄ってみようと思う。


 


・CloudFormationに期待すること


 設定さえしておけばAWSのサーバ立ち上げまでをワンクリックでぜんぶやってくれるシステム。

 設計図作りもドラッグ&ドロップの直感的なGUIで、AWSでよくある構成図みたいなのを作っていくイメージ。あとは既存のVPCをそのままイメージ化できたりとかして欲しいなぁ。期待大。


 


・そもそもCloudFormationとは?


 AWSのインフラ構成状況の設定を記録しておいてくれるサービス。インフラの構成を一つ一つ手動でやる必要がないということがメリットだ。

 人の手だとどうしても選択間違いやロード時間の遅さに起因したイライラ間違い等がおこりやすい。だが、これを使えば簡単な操作でインフラのセットアップを全部やってくれるのだ。

 この真価は、「誰がやっても簡単に同じものができる」ということではないだろうか。仕事において「誰がやっても同じクオリティ」「簡単ですぐにできる」「間違いがない」ことは非常に重要なことだ。それらをかなえてくれる。


 そして料金体系。以下の通りとなっている。

作成は無料

・インスタンスの起動ごとに課金


 つまり、作成と保存はいくらでもできる(S3等、テンプレートを保存する場所は別途課金)のだ。「あの環境向けにはこのテンプレート」「この環境にはこのバージョン」といった風に、バージョン・タイプをいくらでも作成と保存ができるのは即応性があり、なおかつ誰がやっても間違いがない安全性がある。


 


・UIはどんな感じか


 作成に当たってはJSON / YAMLで記載したテンプレートのほか、ビジュアルで直感的操作ができるGUIもある。やはりあるか、という安心感と期待感が膨らんでくる。これなら私も簡単に作れそうだ。

 GUIはドラッグアンドドロップでVPCからインスタンスまで追加できる。しかもCloudFormationにCloudFormationを二重で設定できるようだ。このとき、ドラッグ&ドロップで追加するとテンプレートに勝手に記載されていく。JSON形式とYAML形式で相互変換してくれて、自由に変形可能。

 また、既存の構成からCloudFormationに落とし込む、CloudFormerというサービスもある。しかし残念ながらまだBeta版なので注意だ。


 


・実際に作成してみる


 CloudFormationDesignerという機能が、私の求めるGUIベースの作成機能のようだ。ということでとりあえずCloudFormationDesignerを弄ってみる。(・・・・・・JSONとかYAMLとか書くよりとりあえず楽に直感的に作りたい。初見で簡単に作れることを期待)

 まずはGUIでEC2を選択してみるが、動かない。




 と思ったらどうもサービス名が展開できるようなので、展開してみる。すると、いろいろある。



 とりあえず[インスタンス]の[VPC]をD&Dで方眼上に置いてみると、なるほど。よくあるAWSの構成図のようなものができた。

 次にEC2インスタンスをD&Dで配置してみた。配置するとVPCとEC2の枠上に、丸い「いかにも接続しますよ」というような矢印が出てくる。ドラッグしてみたが、特に接続できる様子はない。IGW等を設定するのだろうか。と思ったら、どうも配置するだけでいいようだ。




 そしてここで疑問が。EC2のインスタンスサイズはどこで設定するのか、である。

 どうもここら辺はパラメータを直接書き込んでやらなければならないようだ。残念だが、一番肝心なところを手書きでやらなければいけないということがわかった。



 ここまで選択肢からのGUIでよかったと思うし、もしGUIでないにしてもヘルプくらいは一箇所にまとめておいてほしかった。一々[?]マークを押して、ヘルプを参照しに行かなければならないのは手間だ。そしてヘルプを参照しに行った先でも、一覧がズラーッと並んでいて非常に探しづらい。私個人の勝手な予想としては、GUIをクリックすると各プロパティの設定画面があってそこのボックスでプチプチ選択するか書き込んでいけばOKみたいなものを予想していただけに、意外とハードルが高いと感じた。


 


・気になったこと、感想


これがよい!


-Vaildationチェッカーがあるのでテンプレートの間違っている箇所を自動で判別して確認をかけてくれるので、いざ立ち上げて失敗しましたといった事態が防げる。

 また、CloudFormerで最初に作った環境をうまいこと量産できる。ただしβ版機能である。


これが困る!


-一目名前を見てサービスを把握できないと、もしくは知っていないと、迅速にサービスを選べない。細かい分類がどうなっているのかも、コンソールをよくよく触って確認しておくべき。ツリーの分類も特に記載とかメモとか無いので一通り触ってみるとよし。でも分類が分かりづらい。


 


・ここまでのまとめ


 そもそもの求めるものとして、私の考え方が違ったらしい。CloudFormationDesignerは“設定ファイルの大枠を作るもの”であり、CloudFormationは本来JSON/YAMLファイルを自分で書いてそれを使用する機能だ。今回はCloudFormationDesignerにフォーカスしたが、設定ファイルをしっかり書けるよう勉強しなければ。


 


・参考資料


<AWS CloudFormation>

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/Welcome.html


<AWS CloudFormer(Beta)>

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-using-cloudformer.html


 


・次回の目標


 JSON/YAMLを書くのはその手の作業の下地が薄いので大変だが、これを乗り越えなければCloudFormationをマスターできないし、ここまで書いて投げ出すわけには行かない。一説によるとテンプレートをマスターするには時間がかかると聞くが、AWSの頭でっかちを脱却すると決めたからにはやるつもりだ。

 というわけで次回は実際記入したJSON/YAMLを解説していこうと思う。

PowerShellでAWSをごにょごにょする(その1)

2017.10.04

スクリプト好きとしては、コンソールに入ってぽちぽちするよりも、

スクリプトで色々いじりたくなるものです。

ということで、Windowsではお馴染みのPowerShellを使って、

AWSリソースを操作してみます。


今回はTools for Windows PowerShellを導入してみます。


①前提条件の確認

AWSアカウントが必要なので、持っていない場合は作成しましょう。


ツールはWindowsベースのコンピュータにインストールするので、

以下のシステム前提条件もチェック。


Microsoft Windows XP 以降

Windows PowerShell 2.0 以降

(Tools for PowerShell Core の場合は PowerShell Core 6.0 以降)


②AWS Tools for PowerShellのインストール

インストーラをダウンロードする方法もありますが、

せっかくなのでPowerShellからインストールしちゃいましょう。


管理者権限でPowerShellを起動して、カタカタします。

途中警告が出たり待たされたりしますが、気にしない。

※プログレスバーが出ないのでので不安にはなりますね



③スクリプト実行の有効化

ポリシーによってはスクリプト実行に制限があるので確認します。

ちなみにポリシー一覧は下記の通りです。


Restricted:構成ファイルの読み込みやスクリプトの実行を行いません。既定値は "Restricted" です。

AllSigned:すべてのスクリプトと構成ファイルが信頼された発行元によって署名されていることを要求します (ユーザーがローカル コンピューターに書き込むスクリプトを含む)。

RemoteSigned:インターネットからダウンロードされたすべてのスクリプトおよび構成ファイルが、信頼された発行元によって署名されていることを要求します。

Unrestricted:すべての構成ファイルを読み込み、すべてのスクリプトを実行します。インターネットからダウンロードされた署名されていないスクリプトを実行する場合、スクリプトを実行する前に確認を求められます。

Bypass:何もブロックされず、警告もメッセージも表示されません。

Undefined:現在のスコープから現在割り当てられている実行ポリシーを削除します。このパラメーターは、グループ ポリシー スコープ内で設定された実行ポリシーは削除しません。


確認したところ、Bypassなので次に進みます。



④インストールの確認

インストールは完了しているはずなので、バージョン情報を見てみます。



⑤操作できるAWSサービスの確認

さっきのコマンドにパラメータを追加すると、サポートされているAWSサービスが表示されます。


Service Noun Prefix API Version

------- ----------- -----------

AWS AppStream APS 2016-12-01

AWS AppSync ASYN 2017-07-25

AWS Batch BAT 2016-08-10

AWS Budgets BGT 2016-10-20

AWS Certificate Manager ACM 2015-12-08

AWS Certificate Manager Private Certificate Authority PCA 2017-08-22

AWS Cloud Directory CDIR 2016-05-10

AWS Cloud HSM HSM 2014-05-30

AWS Cloud HSM V2 HSM2 2017-04-28

AWS Cloud9 C9 2017-09-23

AWS CloudFormation CFN 2010-05-15

AWS CloudTrail CT 2013-11-01

AWS CodeBuild CB 2016-10-06

AWS CodeCommit CC 2015-04-13

AWS CodeDeploy CD 2014-10-06

AWS CodePipeline CP 2015-07-09

AWS CodeStar CST 2017-04-19

AWS Config CFG 2014-11-12

AWS Cost Explorer CE 2017-10-25

AWS Cost and Usage Report CUR 2017-01-06

AWS Data Pipeline DP 2012-10-29

AWS Database Migration Service DMS 2016-01-01

AWS Device Farm DF 2015-06-23

AWS Direct Connect DC 2012-10-25

AWS Directory Service DS 2015-04-16

AWS Elastic Beanstalk EB 2010-12-01

AWS Elemental MediaConvert EMC 2017-08-29

AWS Elemental MediaLive EML 2017-10-14

AWS Elemental MediaPackage EMP 2017-10-12

AWS Elemental MediaStore EMS 2017-09-01

AWS Elemental MediaStore Data Plane EMSD 2017-09-01

AWS Glue GLUE 2017-03-31

AWS Greengrass GG 2017-06-07

AWS Health HLTH 2016-08-04

AWS Identity and Access Management IAM 2010-05-08

AWS Import/Export IE 2010-06-01

AWS Import/Export Snowball SNOW 2016-06-30

AWS IoT IOT 2015-05-28

AWS IoT Jobs Data Plane IOTJ 2017-09-29

AWS Key Management Service KMS 2014-11-01

AWS Lambda LM 2015-03-31

AWS Marketplace Commerce Analytics MCA 2015-07-01

AWS Marketplace Entitlement Service MES 2017-01-11

AWS Marketplace Metering MM 2016-01-14

AWS Migration Hub MH 2017-05-31

AWS OpsWorks OPS 2013-02-18

AWS OpsWorksCM OWCM 2016-11-01

AWS Organizations ORG 2016-11-28

AWS Price List Service PLS 2017-10-15

AWS Resource Groups RG 2017-11-27

AWS Resource Groups Tagging API RGT 2017-01-26

AWS Secrets Manager SEC 2017-10-17

AWS Security Token Service STS 2011-06-15

AWS Serverless Application Repository SAR 2017-09-08

AWS Service Catalog SC 2015-12-10

AWS Shield SHLD 2016-06-02

AWS Step Functions SFN 2016-11-23

AWS Storage Gateway SG 2013-06-30

AWS Support API ASA 2013-04-15

AWS Systems Manager SSM 2014-11-06

AWS WAF WAF 2015-08-24

AWS WAF Regional WAFR 2016-11-28

AWS X-Ray XR 2016-04-12

Alexa For Business ALXB 2017-11-09

Amazon API Gateway AG 2015-07-09

Amazon Athena ATH 2017-05-18

Amazon CloudFront CF 2017-10-30

Amazon CloudSearch CS 2013-01-01

Amazon CloudSearchDomain CSD 2013-01-01

Amazon CloudWatch CW 2010-08-01

Amazon CloudWatch Events CWE 2015-10-07

Amazon CloudWatch Logs CWL 2014-03-28

Amazon Cognito Identity CGI 2014-06-30

Amazon Cognito Identity Provider CGIP 2016-04-18

Amazon Comprehend COMP 2017-11-27

Amazon DynamoDB DDB 2012-08-10

Amazon DynamoDB Accelerator (DAX) DAX 2017-04-19

Amazon EC2 Container Registry ECR 2015-09-21

Amazon EC2 Container Service ECS 2014-11-13

Amazon ElastiCache EC 2015-02-02

Amazon Elastic Compute Cloud EC2 2016-11-15

Amazon Elastic File System EFS 2015-02-01

Amazon Elastic MapReduce EMR 2009-03-31

Amazon Elastic Transcoder ETS 2012-09-25

Amazon Elasticsearch ES 2015-01-01

Amazon GameLift Service GML 2015-10-01

Amazon GuardDuty GD 2017-11-28

Amazon Inspector INS 2016-02-16

Amazon Kinesis KIN 2013-12-02

Amazon Kinesis Analytics KINA 2015-08-14

Amazon Kinesis Firehose KINF 2015-08-04

Amazon Kinesis Video Streams KV 2017-09-30

Amazon Kinesis Video Streams Media KVM 2017-09-30

Amazon Lex LEX 2016-11-28

Amazon Lex Model Building Service LMB 2017-04-19

Amazon Lightsail LS 2016-11-28

Amazon MQ MQ 2017-11-27

Amazon MTurk Service MTR 2017-01-17

Amazon Machine Learning ML 2014-12-12

Amazon Pinpoint PIN 2016-12-01

Amazon Polly POL 2016-06-10

Amazon Redshift RS 2012-12-01

Amazon Rekognition REK 2016-06-27

Amazon Relational Database Service RDS 2014-10-31

Amazon Route 53 R53 2013-04-01

Amazon Route 53 Domains R53D 2014-05-15

Amazon SageMaker Runtime SMR 2017-05-13

Amazon SageMaker Service SM 2017-07-24

Amazon Server Migration Service SMS 2016-10-24

Amazon Simple Email Service SES 2010-12-01

Amazon Simple Notification Service SNS 2010-03-31

Amazon Simple Queue Service SQS 2012-11-05

Amazon Simple Storage Service S3 2006-03-01

Amazon Transcribe Service TRS 2017-10-26

Amazon Translate TRN 2017-07-01

Amazon WorkDocs WD 2016-05-01

Amazon WorkMail WM 2017-10-01

Amazon WorkSpaces WKS 2015-04-08

Application Auto Scaling AAS 2016-02-06

Application Discovery Service ADS 2015-11-01

Auto Scaling AS 2011-01-01

Elastic Load Balancing ELB 2012-06-01

Elastic Load Balancing V2 ELB2 2015-12-01

Firewall Management Service FMS 2018-01-01


次回はEC2を操作してみたいと思います。

SimpleADユーザーとGoogleアカウントを同期させる

2017.09.15

こんにちは。YCです。

前回の記事でSimpleADにユーザーを作成できました。
今回はそのユーザーをG Suiteに連携したいと思います。
連携の為、使用するツールはGoogleの出しているAD連携ツール
「Google Cloud Directory Sync (以下GCDS)」を使用します。

GCDSの仕組み


1,LDAP サーバーまたは Active Directory のリストからデータが書き出されます。ユーザーが、リストの生成方法を指定するルールを設定します。
2.GCDS は Google ドメインに接続し、ユーザーが指定した Google ユーザー、グループ、共有の連絡先のリストを生成します。
3,GCDS はこのリストを比較し、そのデータに合わせて Google ドメインを更新します。
4,同期が完了すると、ユーザーが指定したアドレスにレポートがメールで送信されます。

Google公式ドキュメントより引用



環境準備


まずはGoogleの管理コンソールにログインし、
セキュリティ → API リファレンス →API アクセスを有効にする にチェックを付けます。
スクリーンショット 2017-09-25 17.07.41
これでとりあえずAPIが通るようになりました。

 

環境構築


Google公式の出しているGCDSのダウンロード手順書を見ながら
GCDSをダウンロードします。

ダウンロードしたら、GCDSを開き以下の手順で作業を進めます。
最初に出てくるのはGoogleとの連携です。
Primary Domain NameにGoogleのドメイン名を入力し、
Authrize Nowをクリックします。
09googledomain1
(検証後にスクリーンショットを撮ったので既にAuthrizedになってますが気にしないでください。)

そうすると、このようなポップアップが出てくるので、
Sign inをクリックし、Googleドメインにサインインしてください。
出てくるものを全て承認すると、Verification Codeが発行されるので、
Step2に貼り付けてください。
10googlesignin

次のLDAP認証が鬼門です。
実際のSimpleADへLDAPで接続します。
設定はこのように致しました。
11ldap1
注意して欲しいのが赤い下線部分です。

まず、ホスト名ですが、AWSのリソースであるSimpleADは自分の指定したドメインの前に
AWSのホスト名が付くので注意しましょう。
コマンドプロンプトから nslookup コマンドで確認して入力します。
cmd

次に、ユーザー名です。
ユーザーには事前に全てのユーザー情報の読み取り権限を委任してあげる必要があります。
鬼門なのでユーザーの権限委任から手順を載せていきます。

①グループを作成
01group

②制御の委任をクリック
02inin

③委任ウィザードの開始で次へをクリック
03ininuxiza-do

④追加をクリック
04tugie

⑤先ほど作ったグループを追加
05google

⑥権限を追加
06subeteno

⑦ユーザーを作成し、
07user

⑧先ほどのグループをユーザーに割り当てる
08groupsyozoku

これでようやくLdapが通るユーザーが作成できました。
このユーザーを使用して、「ドメイン名¥ユーザー名」で設定します。

最後にベースDNがわからない場合はLdapブラウザなどで確認してください。
基本的には上記画像のように「DC=xxxxxx,DC=xx」で良いと思います。

では、次の設定に参りましょう。
次のGeneral Settingsはとりあえず下記画像だけで問題ありません。
12general

Org Unitsはチェックをつけてください。
Googleの組織を使用するというチェックです。
13org

ユーザーアカウントの設定はこれと同じように設定するだけで構いません。
14useraccounts1
15useraccounts2

User ruleは以下のように設定しました。
16userrule
ここでのOrg Unit NameはGoogle側の組織名です。
Googleで先に組織を作っておいてください。
17googletest
今回のルールはメールアドレスの最後に.tkが入っているユーザーを見つけるというルールにしています。

次にNotificationsはこのように設定しています。
18notifications
SMTPホストはGoogleから引っ張っております。
21shosaisettei

そして、ログの吐き出し先を指定し、
22log

Syncで全項目にチェックが付いていることを確認してsimulate syncをクリックします。
23simulate

無事、シミュレーションが出来ると、
Google上のユーザ、AD上の検索で出たユーザそれぞれの数が出てきます。
24simulate1

問題がなければSync & apply changesをクリックし、
Googleにユーザーが追加された事を確認してください。
25userkakunin

これにてGoogleとADの同期は完了です。
散々詰まりましたが、こちらのサイト様のおかげで
なんとか同期の確認は取れました。

次回はGoogle Password Syncでパスワードの同期を試します。
ブログに載せられる機会があれば載せます。
以上です。では。
1 / 2212345...1020...最後 »