#ElasticSearchService

[centizen]

Is AWS Elasticsearch Developer’s True Hero?

Elasticsearch is a free open source search engine, which is used for log analytics, full-text search, application monitoring and more. It makes easy to deploy, operate and scale Elasticsearch clusters in the AWS Cloud. We can get direct access to the Elasticsearch APIs. It provides Scalability, Availability and Security for the workload process run.

Elasticsearch architecture

The AWS Elasticsearch Service Architecture is very dynamically to allow create instances, remove instances, change instance sizes, change storage configuration and customize to make other changes. This Elasticsearch allows to search and analyse the data log. It consists of three components.

Logstash – is used to collect and transferred to the Elasticsearch.

Elasticsearch –facilitates search and analyze with the logs stored in it. It acts as a database.

Kibana –Kibana enables the data visualization on the dashboard that uses ELK stack. This tool provides a quick insight of the documents using visualization Kibana’s dashboard contains interactive diagrams, geospatial data, and graphs to visualize complex queries that let you search, view, or interact with the stored data. Kibana helps you to perform advanced data analysis and visualize your data in a variety of tables, charts, and maps.

Get started with an Elastic Cluster with AWS

First, create an AWS account and follow the following steps to claim your domain.

Tap on to “Create a new domain”

Select on the appropriated Deployment type and select the Elasticsearch version. Click Next.

Enter a domain name and choose the Instance type in the prompt page and Click Next.

Follow to enter the “Dedicated master instances”

Click Next.

After the Cluster Configuration, you will be taken to the Set up access part. In the Setup access part, enable the specific set of users who can access your ElasticSearch cluster. There are two options — VPC access and Public access. Once you select one of the options and confirm your entries your new cluster is created.

Things to consider

1. Expandable

Amazon Elasticsearch Service provides to monitor your cluster through Amazon CloudWatch metrics.

We can change the cluster in various size from top or bottom within single clicks in the AWS management console or via a single API call.

There is a customizable setting available based on the range of instance types and storage options including SSD-powered EBS volumes.

2.Integrations

Many integrations available in the AWS Elasticsearch such as Kibana for data visualization, Amazon CloudTrail is used to audit API calls configure in AWS ES domains and integrate with Amazon Amazon S3, Amazon Kinesis, and Amazon DynamoDB for loading streaming data into Amazon ES.

3.Guarantee

It guarantees to provide a secure environment and easy integration with Amazon VPC and VPC security groups. There is an availability to access the Identity and Access Management (IAM) control. It provides authentication for Kibana and Data encryption with node-to-node encryption.

4.Availability

Amazon ES supports the different zones in two geographical locations and various node allocations with a large number of zones in the same region itself. It manages the cluster and notifies the damaged nodes automatically.

Conclusion

This article has covered what AWS Elastic Search means, its benefits, what happens between and how you can use it.

[awsexchage]

続・日本で 128 番目くらいに Ruby で AWS Lambda を試したメモ 〜俺のライブラリを Lambda で動かしたいけど…〜 https://ift.tt/2Cjw900

追記

追記 (3) aws-sdk 以外の gem だけをロードする場合ってどうなのか

検証コード

以下のように furikake で利用する aws-sdk を除いて, 依存している gem を require してみます.

require 'benchmark' def run(event:, context:) Benchmark.bm(10) do |r| r.report 'require gems' do require 'thor' require 'markdown-tables' require 'backlog_kit' end end end run(event: {}, context: {})

結果

# On macOS (Ruby 2.5.1) $ bundle exec ruby lambda.rb user system total real require gems 0.091279 0.049211 0.140490 ( 0.387624) $ bundle exec ruby lambda.rb user system total real require gems 0.091667 0.041068 0.132735 ( 0.133426) $ bundle exec ruby lambda.rb user system total real require gems 0.087537 0.043253 0.130790 ( 0.132725) # On Docker Container (lambci/lambda:build-ruby2.5) bash-4.2# ruby lambda.rb user system total real require gems 0.060000 0.310000 0.370000 ( 1.752973) bash-4.2# ruby lambda.rb user system total real require gems 0.060000 0.190000 0.250000 ( 1.729625) bash-4.2# ruby lambda.rb user system total real require gems 0.140000 0.120000 0.260000 ( 1.668639) # On Lambda user system total real require gems 0.000016 0.000006 0.000022 ( 0.000020) user system total real require gems 0.000021 0.000008 0.000029 ( 0.000026) user system total real require gems 0.000030 0.000011 0.000041 ( 0.000037)

Lambda での処理時間が圧倒的に高速で優秀だと思います. 全く aws-sdk に依存しない gem を利用する場合にはロードに要する時間はとても短いことを確認しました.

見解

これらの結果から, 以下のようなことが言えそうです.

サードパーティ製の gem において,aws-sdk に依存している gem を Lambda で利用する場合, 関数の初回起動時だけ gem のロードに時間が掛かる可能性がる (furikake はまさにそうで, furikake 自身が aws-sdk に依存している)

追記 (2) Ruby ランタイムに組み込まれている gem の一覧

以下, Ruby ランタイムに事前に組み込まれている gem の一覧です. aws-sdk は予め組み込まれていました (そりゃそうだ…).

codestar (1.7.0) aws-sdk-cognitoidentity (1.5.0) aws-sdk-cognitoidentityprovider (1.10.0) aws-sdk-cognitosync (1.5.0) aws-sdk-comprehend (1.8.0) aws-sdk-configservice (1.19.0) aws-sdk-connect (1.8.0) aws-sdk-core (3.37.0) aws-sdk-costandusagereportservice (1.5.0) aws-sdk-costexplorer (1.12.0) aws-sdk-databasemigrationservice (1.13.0) aws-sdk-datapipeline (1.5.0) aws-sdk-dax (1.7.0) aws-sdk-devicefarm (1.12.0) aws-sdk-directconnect (1.8.0) aws-sdk-directoryservice (1.10.0) aws-sdk-dlm (1.6.0) aws-sdk-dynamodb (1.16.0) aws-sdk-dynamodbstreams (1.5.0) aws-sdk-ec2 (1.56.0) aws-sdk-ecr (1.8.0) aws-sdk-ecs (1.22.0) aws-sdk-efs (1.6.0) aws-sdk-eks (1.7.0) aws-sdk-elasticache (1.9.0) aws-sdk-elasticbeanstalk (1.13.0) aws-sdk-elasticloadbalancing (1.7.0) aws-sdk-elasticloadbalancingv2 (1.16.0) aws-sdk-elasticsearchservice (1.14.0) aws-sdk-elastictranscoder (1.6.0) aws-sdk-emr (1.7.0) aws-sdk-firehose (1.8.0) aws-sdk-fms (1.6.0) aws-sdk-gamelift (1.9.0) aws-sdk-glacier (1.13.0) aws-sdk-glue (1.20.0) aws-sdk-greengrass (1.10.0) aws-sdk-guardduty (1.10.0) aws-sdk-health (1.7.0) aws-sdk-iam (1.10.0) aws-sdk-importexport (1.5.0) aws-sdk-inspector (1.11.0) aws-sdk-iot (1.18.0) aws-sdk-iot1clickdevicesservice (1.5.0) aws-sdk-iot1clickprojects (1.5.0) aws-sdk-iotanalytics (1.9.0) aws-sdk-iotdataplane (1.5.0) aws-sdk-iotjobsdataplane (1.6.0) aws-sdk-kinesis (1.8.0) aws-sdk-kinesisanalytics (1.7.0) aws-sdk-kinesisvideo (1.6.0) aws-sdk-kinesisvideoarchivedmedia (1.6.0) aws-sdk-kinesisvideomedia (1.5.0) aws-sdk-kms (1.11.0) aws-sdk-lambda (1.13.0) aws-sdk-lambdapreview (1.5.0) aws-sdk-lex (1.8.0) aws-sdk-lexmodelbuildingservice (1.11.0) aws-sdk-lightsail (1.10.0) aws-sdk-machinelearning (1.5.0) aws-sdk-macie (1.5.0) aws-sdk-marketplacecommerceanalytics (1.5.0) aws-sdk-marketplaceentitlementservice (1.5.0) aws-sdk-marketplacemetering (1.5.0) aws-sdk-mediaconvert (1.16.0) aws-sdk-medialive (1.15.0) aws-sdk-mediapackage (1.9.0) aws-sdk-mediastore (1.6.0) aws-sdk-mediastoredata (1.7.0) aws-sdk-mediatailor (1.6.0) aws-sdk-migrationhub (1.7.0) aws-sdk-mobile (1.5.0) aws-sdk-mq (1.7.0) aws-sdk-mturk (1.8.0) aws-sdk-neptune (1.6.0) aws-sdk-opsworks (1.8.0) aws-sdk-opsworkscm (1.9.0) aws-sdk-organizations (1.15.0) aws-sdk-pi (1.5.0) aws-sdk-pinpoint (1.12.0) aws-sdk-pinpointemail (1.0.0) aws-sdk-polly (1.13.0) aws-sdk-pricing (1.5.0) aws-sdk-rds (1.36.0) aws-sdk-redshift (1.13.0) aws-sdk-rekognition (1.14.0) aws-sdk-resourcegroups (1.7.0) aws-sdk-resourcegroupstaggingapi (1.5.0) aws-sdk-resources (3.27.0) aws-sdk-route53 (1.15.0) aws-sdk-route53domains (1.7.0) aws-sdk-s3 (1.23.1) aws-sdk-sagemaker (1.22.0) aws-sdk-sagemakerruntime (1.6.0) aws-sdk-secretsmanager (1.19.0) aws-sdk-serverlessapplicationrepository (1.9.0) aws-sdk-servicecatalog (1.12.0) aws-sdk-servicediscovery (1.7.0) aws-sdk-ses (1.13.0) aws-sdk-shield (1.8.0) aws-sdk-signer (1.4.0) aws-sdk-simpledb (1.5.0) aws-sdk-sms (1.5.0) aws-sdk-snowball (1.9.0) aws-sdk-sns (1.7.0) aws-sdk-sqs (1.9.0) aws-sdk-ssm (1.32.0) aws-sdk-states (1.7.0) aws-sdk-storagegateway (1.12.0) aws-sdk-support (1.5.0) aws-sdk-swf (1.5.0) aws-sdk-transcribeservice (1.10.0) aws-sdk-translate (1.6.0) aws-sdk-waf (1.10.0) aws-sdk-wafregional (1.11.0) aws-sdk-workdocs (1.6.0) aws-sdk-workmail (1.6.0) aws-sdk-workspaces (1.8.0) aws-sdk-xray (1.8.0) aws-sigv2 (1.0.1) aws-sigv4 (1.0.3) bigdecimal (default: 1.3.4) bundler (1.17.1) cmath (default: 1.0.0) csv (default: 1.0.0) date (default: 1.0.0) dbm (default: 1.0.0) etc (default: 1.0.0) fcntl (default: 1.0.0) fiddle (default: 1.0.0) fileutils (default: 1.0.2) gdbm (default: 2.0.0) io-console (default: 0.4.6) ipaddr (default: 1.2.0) jmespath (1.4.0) json (default: 2.1.0) openssl (default: 2.1.2) psych (default: 3.0.2) rdoc (default: 6.0.1) scanf (default: 1.0.0) sdbm (default: 1.0.0) stringio (default: 0.0.1) strscan (default: 1.0.0) webrick (default: 1.4.2) zlib (default: 1.0.0)

追記 (1) Ruby ランタイムの gem environment

以下のようになっていました.

RubyGems Environment: - RUBYGEMS VERSION: 2.7.6 - RUBY VERSION: 2.5.3 (2018-10-18 patchlevel 105) [x86_64-linux] - INSTALLATION DIRECTORY: /var/runtime - USER INSTALLATION DIRECTORY: /.gem/ruby/2.5.0 - RUBY EXECUTABLE: /var/lang/bin/ruby - EXECUTABLE DIRECTORY: /var/runtime/bin - SPEC CACHE DIRECTORY: /.gem/specs - SYSTEM CONFIGURATION DIRECTORY: /var/lang/etc - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /var/runtime - /var/task/vendor/bundle/ruby/2.5.0 - /opt/ruby/gems/2.5.0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - https://rubygems.org/ - SHELL PATH: - /var/lang/bin - /var/lang/bin - /usr/local/bin - /usr/bin/ - /bin - /opt/bin

これは

俺でもわかる！俺でもわかった！ことを将来の俺達のために残すアドベントカレンダーです 俺でもわかるシリーズ Advent Calendar 2018 - Qiita - Qiita

qiita.com

俺でもわかるシリーズ Advent Calendar 2018 第 8 日目の記事になる予定です.

集え、初老丸達よ。初老丸達による世界に向けた技術的（又はそれに関連する）な物語を綴るカレンダーです。我こそ初老丸という方、初老丸予備軍の方も奮ってご参加下さい。ジーク・初老丸！ 初老丸 Advent Calendar 2018 - Qiita - Qiita

qiita.com

初老丸 Advent Calendar 2018 第 12 日目の記事になる予定です.

tl;dr

昨日, 以下のような記事を書きました.

# これは初老丸アドベントカレンダー 2018 の 8 日目の記事になる予定です.https://ift.tt/2SOSxUe 加藤さん, 事件です.ずっと待たれ... 日本で 128 番目くらいに Ruby で AWS Lambda を試したメモ - Qiita - Qiita

qiita.com

Ruby が AWS Lambda 上で動くなんてすごいなあと興奮していたのもつかの間, 自分で作ったライブラリが動くかなあと試そうとして躓いた (今も躓いている) ので, メモっておきます.

あれ, 関数の起動が遅いよ…これ

furikake を Lambda で

以下のような issue を立てて, furikake を Lambda 上で動かしてみようとしました.

AWS Lambda 上で動くかどうか試す https://ift.tt/2KPfap3 AWS Lambda 上で動くかどうか試す · Issue #42 · inokappa/furikake - GitHub

github.com

以下のようなエントリーポイントになるコードを書いて sam でローカルテストを実行するところまで漕ぎ着けました.

require 'furikake' def run(event:, context:) report = Furikake::Report.new report.show end

以下, 実際の実行例です. 関数のタイムアウト自体は 60 秒に設定しています.

$ echo '{"test":"dayo"}' | sam local invoke ServerlessFurikake 2018-12-01 07:26:47 Reading invoke payload from stdin (you can also pass it from file with --event) 2018-12-01 07:26:47 Found credentials in shared credentials file: ~/.aws/credentials 2018-12-01 07:26:47 Invoking lambda.run (ruby2.5) Fetching lambci/lambda:ruby2.5 Docker container image...... 2018-12-01 07:26:49 Mounting /path/to/serverless-furikake as /var/task:ro inside runtime container 2018-12-01 07:27:50 Function 'ServerlessFurikake' timed out after 60 seconds

あれ…なんでや…タイムアウトしてしまいました.

何が起きているのか

gem のロードが遅くない？？

furikake は aws-sdk 等の幾つかの gem に依存しているのですが, これらの gem のロードが遅いんじゃないかな…という仮説を立ててみました. ほんとにそれくらいしか思いつかなかったので. ということで, ローカル環境と sam invoke local で実行する Docker コンテナ環境, Lambda 環境の三環境で gem の読み込み速度の比較をしてみたいと思います.

検証環境

sam は local invoke する際に Docker コンテナを起動して, そのコンテナ上で関数を実行しているので, そのコンテナ上でデバッグしてみたいと思います.

尚, 利用する Docker イメージは以下のイメージです.

Docker images and test runners that replicate the live AWS Lambda environment - lambci/docker-lambda lambci/docker-lambda - GitHub

github.com

また, Docker を動かしている環境は以下の通りです.

$ sw_vers ProductName: Mac OS X ProductVersion: 10.13.6 BuildVersion: 17G65 $ ruby --version ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]

ハードウェア的には以下の通りです.

MacBook Pro (Retina, 13-inch, Early 2015)

2.7 GHz Intel Core i5

16 GB 1867 MHz DDR3

2018 年でも快適に利用出来る環境だと思います.

で, 一旦, furikake から離れて, シンプルな検証用のコードを書いて検証してみます.

require 'benchmark' def run(event:, context:) Benchmark.bm(10) do |r| r.report 'require aws-sdk' do require 'aws-sdk' end end end run(event: {}, context: {})

gem は bundle init で Gemfile を生成して以下のように記載して bundle install --path vendor/bundle と実行してインストールしました.

# frozen_string_literal: true source "https://rubygems.org" git_source(:github) {|repo_name| "https://github.com/#{repo_name}" } gem 'aws-sdk'

以下のようなディレクトリ, ファイル構成となります.

$ tree . -L 2 . ├── Gemfile ├── Gemfile.lock ├── lambda.rb ├── template.yaml └── vendor └── bundle 2 directories, 4 files

ローカル環境

以下のように, real で 1.5 秒程度掛かっていますが, 2 回目以降は 0.5 秒程度となり, 個人的に違和感はありません.

$ bundle exec ruby lambda.rb user system total real require aws-sdk 0.327319 0.268804 0.596123 ( 1.496711) $ bundle exec ruby lambda.rb user system total real require aws-sdk 0.296917 0.187150 0.484067 ( 0.489871) $ bundle exec ruby lambda.rb user system total real require aws-sdk 0.299350 0.188319 0.487669 ( 0.494612)

sam の local invoke で利用する Docker 環境

以下のようにコンテナを起動します.

$ docker run -t -i --rm -v "$PWD":/var/task lambci/lambda:build-ruby2.5 /bin/bash

以下のように 100 秒以上掛かるようになりました.

bash-4.2# ruby lambda.rb && ruby lambda.rb && ruby lambda.rb user system total real require aws-sdk 27.580000 8.450000 36.030000 (119.208587) user system total real require aws-sdk 25.780000 9.320000 35.100000 (105.250906) user system total real require aws-sdk 24.730000 9.860000 34.590000 (102.976592)

あれ.

Lambda 環境 (sam でデプロイ)

sam を使ってデプロイしてマネジメントコンソールで確認します. タイムアウトは最大の 15 分に設定しています.

user system total real require aws-sdk 17.486155 1.504303 18.990458 (232.400251) user system total real require aws-sdk 0.000095 0.000008 0.000103 ( 0.000101) user system total real require aws-sdk 0.000026 0.000002 0.000028 ( 0.000025) user system total real require aws-sdk 0.000026 0.000002 0.000028 ( 0.000025)

初回が鬼のように時間が掛かっています. 2 回目以降は 1 回目が嘘のように速くなっていて, むしろローカル環境で実行するよりも速くなっています. どのような仕組みになっているかは分かりかねますが, gem がキャッシュに載っているんだと思います… きっと.

エントリーポイントになるコードを修正して, デプロイし直したところ, キャッシュを含む環境が破棄されて新しい環境に展開される為, 初回起動と同じくらいの起動時間を要してしまいました.

user system total real require aws-sdk 18.216496 1.705607 19.922103 (243.839962) Hello. user system total real require aws-sdk 0.000100 0.000010 0.000110 ( 0.000107) Hello.

なぜか, 初回起動時だけ 2 回 require 'aws-sdk' が実行されているのは…すいません. コードの問題だとおもいます.

Lambda 環境 (手動で Lambda 関数を作成)

マネジメントコンソールにて手動で Lambda 関数を作って, コードを貼り付けてテストしてみます.

user system total real require aws-sdk 0.264964 0.043559 0.308523 ( 3.765794) user system total real require aws-sdk 0.000027 0.000004 0.000031 ( 0.000027) user system total real require aws-sdk 0.000024 0.000004 0.000028 ( 0.000026)

初回起動時は 3 秒ほど掛かっていますが, 2 回目以降は一瞬です. Ruby ランタイムには既に aws-sdk が利用可能な状態で組み込まれているようですので, 単純に aws-sdk だけを利用する Lambda 関数を実行する場合には, この程度の起動時間を要すると考えておくと良さそうです.

結果のまとめ

Lambda 環境では初めて関数を起動する際, サードパーティ製 gem のロードに時間を要する場合があるので気長に待つ (タイムアウトは長めに設定しておく必要がある)

2 回目以降の実行は爆速, コードを変更してデプロイし直すと環境は破棄されて gem を再ロードしてしまうので…起動は遅くなる

sam を使ってローカル実行する場合には, 毎回 gem をロードしてしまうので注意 (そんなもんだと割り切るしかないのかな…)

以上

初回起動時間にさえ注意すれば, 多くの Ruby ライブラリを Lambda 上で動かすことができそうです！

ということで, furikake を動かせそうな気がしてきました.

元記事はこちら

「続・日本で 128 番目くらいに Ruby で AWS Lambda を試したメモ 〜俺のライブラリを Lambda で動かしたいけど…〜」

December 18, 2018 at 12:00PM