【AWS入门】搭建AWS Elasticsearch服务与EC2上的Web应用程序进行集成

2 年 ago
文, 翔
1 minute

以下是VSCode Remote Containers扩展插件在构建.NET Core + MySQL + Elasticsearch开发环境的继续部分。

我计划介绍如何在AWS上构建Elasticsearch，以及如何从部署在EC2实例上的Web应用程序进行连接。

环境

Elasticsearch 7.8 可用。

创建Elasticsearch实例

首先，我们需要创建一个Elasticsearch实例。
请按照以下步骤打开Elasticsearch控制台，并打开创建域的菜单。

    1. 登录AWS管理控制台

 

    1. 在“服务”下的“所有服务”中输入Elasticsearch

 

    1. 点击显示Elasticsearch服务的链接

 

    显示Elasticsearch服务控制台后，点击“创建新域”

将其分为不同的部分进行解释。

步骤1：选择部署类型

选择部署类型为“开发和测试”。
选择Elasticsearch的版本为“7.8”。

スクリーンショット 2020-11-03 20.32.09.png

※顺便说一句，我第一次尝试Elasticsearch时，最新版本是7.7，而现在（2020年11月3日）已经更新到7.8了，这之间只有大约一个月的时间。我一直感觉AWS的Elasticsearch无法使用最新版本，但这个不满或许也会逐渐解消吧。

步骤2：域名设置

关于这个部分

考虑到实际应用情况，此实例和卷的设置将直接影响性能和成本，因此是非常重要的选择。本次选择是基于学习的免费选项，但如果考虑建立生产环境，请在对各个部分有深入理解的基础上做出决策。详细信息请参阅此处。

确定域名

首先决定域名。这次我们选择了”my-elasticsearch”。

スクリーンショット 2020-10-20 14.58.52のコピー.png

数据节点

接下来是数据节点的配置。
实例类型将选择免费套餐中的“t2.small.elasticsearch”。
将节点数设置为“1”。

スクリーンショット 2020-10-20 14.58.52のコピー2.png

数据节点存储

接下来，我们将设置数据节点的存储需求。
这次我们将选择最便宜的EBS卷类型“磁性”来进行设置，其他保持默认设置。

スクリーンショット 2020-11-03 21.00.07.png

专用主节点

因为默认情况下是无效的，所以让我们继续前进。

设置快照的配置

由于Elasticsearch版本5.3之后无法进行此设置，所以让我们继续前进吧。

步骤三：访问和安全设置

接下来，我们将进行网络和认证周边的设置。

网络配置

请选择「VPC访问（推荐）」。
请为VPC和子网分配预先创建的资源。
对于安全组，请分配开放了HTTPS端口的资源。

スクリーンショット 2020-10-20 15.04.17.png

Kibana引用时的身份验证系统

    • 細かいアクセスコントロール – Open Distro for Elasticsearch を搭載

 

    • Kibana の SAML 認証

 

    Amazon Cognito 認証

关于这三个问题，主要是关于配置参考Kibana的认证设置。由于本次目的是运行Elasticsearch，所以不再详述，但在搭建生产环境时，我认为会使用Kibana作为Elasticsearch的控制台，因此不要忘记这个设置项的存在。

スクリーンショット 2020-11-04 23.39.49.png

访问策略

如果需要对用户、角色或特定IP进行功能单元详细的访问控制，我们将进行如下设置。在本次设置中，我们将允许VPC内的任何访问，所以将设置为“允许对域的开放访问”。

スクリーンショット 2020-11-05 0.27.02.png

加密

请将请求和数据加密设置。此设置将提高数据的机密性。
这次只需选中默认设置中的“要求所有流量通过 HTTPS 进行传输”。

スクリーンショット 2020-11-04 23.51.49.png

任何的集群配置

这次我们没有特别更改设置，但我随便调查了一下各个项目的意义和用途，现在分享给大家。

请求体中的索引

在默认情况下，将值设置为true可以启用请求体内的索引指定，正如其名称所示。
而将其设置为false的用途似乎是为了防止用户对意外索引进行操作。

现场数据的缓存分配

为了提高吞吐量，Elasticsearch被配置为缓存字段数据。
此设置将配置缓存区域相对于Java堆大小的比例。
默认情况下，它是无限制的，可能会导致OutOfMemory错误。
此外，根据AWS官方文档，还记载了以下信息。

建议开始使用indices.fielddata.cache.size进行基准测试，因为很多客户每天都会执行旋转索引的查询。在大多数用例中，请将JVM堆设置为40%。然而，如果存在非常大的索引，则可能需要更大的字段数据缓存。

如果你能把默认设置为40%，那就太好了…

句子的最大计数量

在使用搜索API时，bool类型子句有使用限制。我们很难想象会有超过默认值1024的条件指定，但如果要处理这种罕见情况，就需要调整这个值。然而，如果将上限设置得太高，可能会导致TooManyClauses错误的风险。

スクリーンショット 2020-11-04 23.57.51.png

第四步：确认

确认内容后，点击“确认”按钮即可创建域名。

将创建的Elasticsearch的URL写入Service的环境变量中。

完成最后一项任务，我们需要编辑服务的环境变量，以便能够从先前创建的应用程序中引用Elasticsearch实例。
在SSH到EC2实例后，执行以下命令。

$ sudo vim /etc/systemd/system/kestrel-asp-net-app.service

#Environment=ASPNETCORE_ENVIRONMENT=Production以下に追加
Environment=DB_CONNECTION_STRING=server=サーバのエンドポイント;uid=admin;pwd=パスワード;database=asp_net_sample
Environment=ELASTIC_SEARCH_SERVER=VPCエンドポイント

在Elasticsearch Service管理控制台中，VPC终端节点的信息可以在选择域并显示域详细信息的界面找到。

请将环境变量 “DB_CONNECTION_STRING” 设置为连接到可访问的数据库的连接字符串，无论是在RDS还是在EC2内。
关于如何建立RDS，请参考此处。

设定完成后，为了反映变更，需要重新启动EC2实例。

确定

请在本地机器上用浏览器打开http://服务器IP/。
由于Elasticsearch实例刚刚被创建，因此索引不存在，请点击初始化环境。
如果搜索执行成功，则表示正常运行。

タイトルなし.gif

链接

AWS Elasticsearch Service的官方文件

以下为我个人用的备忘录。

工作负载

・长期指数：指保持较长时间的指数。当使用Elastic Search作为搜索服务时，采用此方法。预计需要进行维护工作，如在数据模式更新等情况下更新索引内容。
硬盘需求取决于存储搜索结果所需的数据量。

・滚动索引：保留特定时间范围的数据的索引。适用于进行日志分析等只针对最近数据的分析。对硬盘要求取决于日志等的输出频率。

存储需求的详细说明

    • レプリカ：インデックスの完全なコピー。完全なコピーのため、ストレージ要件も同様。耐障害性を考慮した場合に少なくとも一つ以上のレプリカが必要。検索のスループットも考慮した場合はさらに必要になる場合もある。

 

    • インデックス作成時のオーバーヘッド

 

    • インデックス作成時のオーバーヘッドにより、実際のディスク上のサイズはソースデータよりも10%大きくなることが見込まれるらしい…

 

    • オペレーティングシステムの予約済み領域

 

    • Linuxにおけるデフォルトの占有領域。rootユーザ用にファイルシステムの5%を予約している。

 

    • Amazon ESのオーバーヘッド

 

    Amazon ESにおけるデフォルトの占有領域。各インスタンスのストレージスペースの20%(最大で20GiB)を予約している。

基于以上条件，存储需求的公式如下：
源数据 * (1 + 复制数) * (1 + 索引创建开销) / (1 – Linux预留空间) / (1 – Amazon ES开销) = 最小存储需求

如果简单计算的话，公式如下：
源数据 * (1 + 副本数) * 1.45 = 最小存储需求

对其他实例的注意事项

・如果最小存储需求超过1PB：亚马逊 Elasticsearch 服务的PB级别存储
・如果采用Rolling Indices并选择热暖架构：亚马逊 Elasticsearch 服务的UltraWarm模式

关于认证和权限

关于ElasticSearch服务对域名的访问限制方法

    • Resource-based Policies

 

    • リソースに対する許可アクションを、ユーザ、アカウント、ロールに対して設定することのできるアクセスポリシー。

 

    • 権限は常にResource要素に指定されたドメイン配下のサブリソースにのみ適用される。

 

    • また、このポリシーで宣言された許可アクションについては、ドメインではなく、ドメインのサブリソースに対してのみ適用されるものであり、ドメインの構成を変更するようなアクションについては許容されない。前述のようなアクションを許容するにはIDベースのポリシーを利用しなければならない。

 

    • Identity-based Policies

 

    • AWSのIAMを使用したアクセスポリシー。

 

    • 権限は常にResource要素に指定されたドメインにのみ適用される。

 

    • Resource-based Policiesとは異なり、ドメインの構成に対するアクションも許容することができる。

 

    • また、Resource-based Policiesとの違いとして、IAM内のユーザ、またはロールにアタッチするため、Principalの設定値を記述しなくて良いことが挙げられる。

 

    • 本番運用する場合にはこちらを使用して権限を抽象化した方が良さそう。

 

    • IP-based Policies

 

    • IPアドレス、またはCIDRブロックを使用したアクセスポリシー。

 

    Amazon ESドメインに署名されていないリクエストを許容できるので、curlやKibanaなどのクライアントを使用したり、プロキシサーバーを介してドメインにアクセスしたりすることができるようになる。
✖
广告
将在 10 秒后关闭
bannerAds