intercomでusersとleadsをarchiveして月額料金を抑える

intercomの課金体系

Subscription___Subscription___competency-cloud運用サポート___Intercom
スクリーンショット 2019-06-13 10 39 55

intercomの課金体系は、intercomにレコード(保存)されたusersとleadsの数によって決まる

intercomの課金体系では、使えば使うほどusers、leadsが増えて利用料金が上がる
もしintercomに保存された全てのデータが必要ならばお金を払えばいいが、そうでない場合は困るので、これをスリム化させたい

課金対策

やりかた

usersとleadsをarchiveする

手順

Users___competency-cloud運用サポート___Intercom

1、Platformにアクセス
2、archiveする対象を選択し、archiveする
終わり

archiveのコツ

  • archiveする対象が定まっている場合は、フィルターを作っておけばいい
    *ちなみにこの運用では「これまで一度も問い合わせをしてこなかったuserとlead」をarchiveしていた

自動でやりたい場合

  • seleniumで定期実行すればうっかり忘れて、課金タイミングになってしまうことを防げる

2019/08/04 AWSの料金モニタリング

値段のコントロールが難しいので週1で確認するようにする

2019/08/04時点

どうやら、EC2のスナップショットのストレージが今月終わりには無料で使える量の4倍以上の量を使うことになるらしい。。

スナップショットといえばバックアップ用にインスタンスのデータを保存しておく機能だが、手動で取っている覚えはないので、もしかすると短いスパンで自動で取得されてるのかもしれないので調査。。

特にスナップショットが自動で撮られているということはなさそう。。なんだこれ?

引き続き値が増えないか観察する

Amazon Certificate ManagerでEC2をSSL化させる

AWS側の設定

Certificate Managerを選択する

「パブリック証明書のリクエスト」を選択し、「証明書のリクエスト」を押す

「ドメイン名」を入力し、「次へ」を押す

ドメインのDNSを変更する権限を持っているので、「DNSの検証」を選択し、「確認」を押す

設定するドメインを確認して、「確認とリクエスト」を押す

どうやらドメインのDNSにCNAMEのレコードを作らなければならないようなので、「DNS設定をファイルにエクスポート」し、設定を確認する

Route53でDNS設定をしている場合はワンクリックでできる

今回はHTTPSリダイレクトを実現するので、もちろんサーバー証明書が必要となります。AWSではCertification Manager(通称ACM)という無料でサーバー証明書が発行できるサービスがあるので、それを利用します。ですがこのサーバー証明書、EC2インスタンス上に置くことはできず、CloudFrontもしくはLoadBalancerに置いてEC2インスタンスに接続するという形を取らなければなりません。

ttps://qiita.com/nszknao/items/b4661452c31a5c6b00d9

今回は記事に倣って、LoadBalancerに証明書を設置する

「リスナーの追加」でHTTPSを追加し、「アベイラビリティーゾーン」を設定する

「ACMから証明書を選択する」を選択し、先ほど作った証明書をセットする

インスタンスで使っているセキュリティグループを選択

成功コードは301にする

SSL化させるインスタンスを選択する

確認を通して作業完了

wordpress側の設定

管理画面から「wordpressアドレス」と「サイトアドレス」を「https://~」にする

cssやjsをhttpsで呼べるように「SSL Insecure Content Fixer」のプラグインを導入して画像のように設定する

以上で作業は完了

無料でドメインを取得して、Route53を使ってEC2のIPに紐づける

手順

大まかな流れ

  • ドメインを取得する
  • AWSのroute53でホストゾーンを作成する
  • ドメインのサイトでネームサーバーに、route53のNSレコード値を転記する
  • route53のホストゾーンにAレコードに設定して、EC2のIPv4とドメインの結び付けを行う

freenomでドメインを取得する

https://my.freenom.com

freenomを使うのは無料だし、トップレベルドメインにこだわらないから

とりあえず、「.ga」を頂くとする

「12 Months @ FREE」であることを確認する

「Forward this domain to」は現在のEC2のアドレスを入力

googleアカウントでログインしてお会計

「ユーザー詳細」を入力してsubmitする

これで登録は完了し、取得したドメインにアクセスすると、「Forward this domain to」に入力したアドレスに飛ぶようになる

ただし、これだと取得したドメインがリダイレクトをさせているに過ぎないので、例えば記事ページに飛んでも、「orelog.ga/archives/〇〇」のようにならず、「orelog.ga」のままで変わらなくなる

こうならないようにするためには、DNSを設定してドメインの読み替えを設定する必要がある

Route 53を利用してDNSを設定する

AWSのRoute53でネームサーバーを設定する

AWSにログインして、「Route 53」を選択し、「ホストゾーン」から「ホストゾーンの作成」を選択する

ドメイン名は「取得したドメイン」のみを入力する

必要事項を入力し、「作成」を押す

すると、ネームサーバー情報が出てくるのでこれを全てコピーする

Freenomからネームサーバー設定画面を開き、先ほどのネームサーバー情報を貼り付ける

これでfreenom側での設定は完了 

route53でAレコードを設定する

以上で設定は完了

参考:https://qiita.com/Yuki_BB3/items/effdf1bb38263bfef82a

トラブルシューティング

上記の設定を行なったが、ドメインにアクセスしても「このサイトにアクセスできません」となる

・digコマンドで設定が反映できているかを確認する

dig 取得したドメイン +noedns +answer

・route53の各種レコードのTTL設定を確認する

設定されているTTLの時間分が経過しないと反映されないので、設定されている時間を確認する

ドメインの有効期限確認方法

ヘッダーから「Renew Domains」を選択する

取得しているドメインと有効期限の一覧が見られる

有効期限の更新もここから

参考:https://qiita.com/teekay/items/135dc67e39f24997019e

wordpressを運用しているEC2にElastic IPを振った場合DBの「siteurl」と「home」を変更しなければならない

問題

wordpressの各ページのURLは、DB内のoptionsテーブルの「siteurl」と「home」を参照している

EC2にElastic IPを振ったり、ドメイン設定をしたりする際はこちらも変更しないと、正しい場所を読みに行かなくなる

変更しないと、ブラウザから接続した際にタイムアウトしたり、正しくファイルが読み込まれなくなる

対応

一般設定から「WordPressアドレス(URL)」と「サイトアドレス(URL)」を変更する

これで正しくページが読み込まれた

linuxサーバーにてsftpユーザーに対してumaskを設定する方法

問題の背景

 サーバーにSSH接続せずに作業するユーザーが複数いて、ファイルを共同で編集するという環境下において、ファイルをアップロードした際にデフォルトのパーミッションを設定しておかないと、いちいちroot権限を引っ張り出して対応しなければならなくなる。
 sftpユーザーへのumask設定は、ssh接続をするユーザーへのumask設定とはやり方が異なる。
 やりたい動きとしては、複数のsftpユーザーがそれぞれにアップロードしたファイルを、全てのユーザーが編集できるようにしたい、ということ。

問題

umaskの設定はetc/profileに記載してもsftpユーザーには効かない

対応

sshd_configにsftp用のumaskを設定する

権限が緩くなる設定なので、対象は指定したgroupに属するユーザーにのみとする

/etc/ssh/sshd_config

Subsystem sftp internal-sftp -u 002

Match Group sftp-user
ForceCommand internal-sftp -u 002

sshdの再起動

service sshd restart

sftp-userでのアップロード確認

アップロード後の権限は以下の通り

フォルダ:775
ファイル:664

t2.microで作成されたEC2インスタンスにSwap領域を追加する

現状の確認

現状のSwap領域

[root@ip-172-31-47-254 ec2-user]# grep Swap /proc/meminfo
SwapCached:            0 kB
SwapTotal:             0 kB
SwapFree:              0 kB

Swap領域は設定されていない

Swap領域を拡張

Swap領域を1GB分設定する

[root@ip-172-31-47-254 ~]# dd if=/dev/zero of=/swapfile1 bs=1M count=1024 1024+0 レコード入力 1024+0 レコード出力 1073741824 バイト (1.1 GB) コピーされました、 15.3432 秒、 70.0 MB/秒

ファイルが作成されたことを確認する

[root@ip-172-31-47-254 ~]# ll /swapfile1
-rw-r--r-- 1 root root 1073741824  7月 18 05:58 /swapfile1

Swapファイルの権限を変更

[root@ip-172-31-47-254 ~]# chmod 600 /swapfile1

作成したスワップファイルをSwap領域用にフォーマットする

[root@ip-172-31-47-254 ~]# mkswap /swapfile1
スワップ空間バージョン 1 を設定します。サイズ = 1024 MiB (1073737728 バイト)
ラベルはありません, UUID=bdbadc63-74f1-4528-92fb-420ba78f0945

Swapファイルを有効化してSwap領域のサイズを増やす

[root@ip-172-31-47-254 ~]# swapon /swapfile1

Swap領域が増えたことを確認する

[root@ip-172-31-47-254 ~]# swapon -s
ファイル名				タイプ		サイズ	使用済み	優先順位
/swapfile1                             	file    	1048572	0	-2

無事に増えている

参考

https://qiita.com/na0AaooQ/items/278a11ed905995bd16af

t2microにてwordpressを運用していたが、度々mysqlがダウンしていた話

wordpress運用環境

  • AWS t2micro
  • Server version: Apache/2.4.39 ()
  • mysql Ver 14.14 Distrib 5.7.26, for Linux (x86_64)
  • amazon linux

t2microのスペック

https://aws.amazon.com/jp/ec2/instance-types/

ダウン現象

 wordpressの記事更新をする際にメモリの使用量が1GBを超える
以下はインスタンスタイプをt2.xlargeにした際に検証を行い、topコマンドでモニタリングしたもの

top - 02:42:42 up 4 days, 16:52,  3 users,  load average: 0.20, 0.13, 0.05
Tasks: 140 total,   2 running,  89 sleeping,   0 stopped,   1 zombie
%Cpu(s):  8.8 us,  0.6 sy,  0.0 ni, 90.4 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem : 16424208 total, 13677544 free,  1198980 used,  1547684 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 14903952 avail Mem

間違った対応

2019-04-18 02:37:52 5604 [Note] InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
2019-04-18 02:37:54 5604 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-04-18 02:37:55 5604 [ERROR] Plugin 'InnoDB' init function returned error.
2019-04-18 02:37:55 5604 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-04-18 02:38:08 5604 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-04-18 02:38:08 5604 [ERROR] Aborting

上記のエラーを見て、innodb_buffer_pool_sizeがデフォルトの128.0Mでは足りないと判断を設定し、これを通常そのようにするらしい、「メモリの8割のサイズを設定する」というものにする

innodb_buffer_pool_size : InnoDBを使っている場合、どんな環境でも一番最初に設定しなければならない値。 バッファプールとは、データとインデックスがキャッシュされる領域だ。 これをできる限り大きくしておくことで、読み出しの処理をディスクからではなくメモリから行うことができるようになる。 一般的な値は、5-6GB(8GB RAMの場合)、20-25GB(32GB RAM)、100-120GB(128GB RAM)。

https://yakst.com/ja/posts/200

ただし、そもそもmysql処理にかかるメモリがインスタンスのメモリサイズをオーバーしていたことが原因だったので、これではmysqlダウンの現象解決にはならない
解決策はメモリを増やすか、swap領域を拡張する必要があったのではないかと考えた

スワップ領域を増やす方向で考える

スワップ領域とは

スワップ領域とは 使っていないメモリの内容を一時的にしまっておくための場所 です。

https://wa3.i-3-i.info/word1721.html

つまり、「メモリが足りないならHDに保存すればいいじゃない!」という話
ちなみにインスタンスのストレージは「EBS のみ」となっている

EBSとは

Amazon Elastic Block Store (Amazon EBS) は、AWS クラウド内で Amazon EC2 インスタンスと組み合わせて使用できる、永続的なブロックストレージボリュームです。コンポーネントに障害が発生した場合でも高い可用性と耐久性を提供できるように、各 Amazon EBS ボリュームはアベイラビリティーゾーン内で自動的にレプリケートされます。Amazon EBS ボリュームは、作業負荷の実行に必要な安定した低レイテンシーのパフォーマンスを提供します。Amazon EBS を使用すると、使用量の拡張または縮小を分単位で行うことができます。プロビジョニングしているサイズに合わせて、低料金でご利用いただけます。

https://aws.amazon.com/jp/ebs/

気になるお値段(というか課金体系)

EBS 汎用 SSD (gp2) ボリューム 汎用 SSD (gp2) ボリュームのボリュームストレージの料金はプロビジョニングした容量 (GB/月) で決まり、お客様がそのストレージを解放するまで毎月料金が発生します。gp2 ボリュームのプロビジョニング済みストレージは、1 秒ごとに課金されます (最小課金時間は 60 秒)。I/O はボリュームの料金に含まれているため、プロビジョニングした各ストレージの GB に対してのみ課金されます。

*プロビジョビングとは

プロビジョニングとは、必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくことです。供給や設備等の意味を表すプロビジョン(provision)という単語がもととなって派生した言葉です。

つまり使った分だけお値段が発生するってこと

今回の運用ではメモリのオーバー幅は500MBくらいなので、EBSにスワップ領域を確保してもそんなにお金はかからないと判断

念のためのシミュレーション結果

プロビジョニングされたストレージ 1 GB の月額料金が 0.12USD

https://aws.amazon.com/jp/ebs/pricing/?nc=sn&loc=3

だいたい0.06USD/月か オーライ

本当に落ちないのか検証する

今回のダウン騒動で、問題のインスタンスはサイズアップをしてしまったので検証はできず。。
なので個人でAWSでwordpress使って技術ブログでも運用してみるとする