LightsailでCloudWatch Logsに保管する
こんにちは。かじです。
今回はCloudWatch LogsでLightsailのログを収集する方法について解説します。
CloudWatchLogsではEC2やオンプレミスのサーバのログを収集し保管することができる機能です。EC2やオンプレミスのサーバが基本的な用途ですが、LightsailでもCloudWatch Logsでログを収集、保管することはできます。ログを収集する際にはインターネットを介してログをCloudWatchに送るだけですし、内部で動いているOSはLinuxですので、なんら問題はありません。
とりあえずやってみましょう。
1.IAMユーザーを作成する
LightsailもEC2オンプレミスと変わらないから問題ないはと言ったものの、いきなり問題発生です。LightasailにはIAMロールをアタッチできません。
解決方法は、IAMユーザーを使用することです。とりあえず、これ用のIAMユーザーを作成し、アクセスキーとシークレットキーを控えてください。
2.Lightsail側の設定
aws configureでプロファイルを作成
LightsailインスタンスにSSHで接続し、下記コマンドでaws configureプロファイルを作成します。
$ sudo aws configure --profile AmazonCloudWatchAgentプロファイル名は適当で、作成したIAMユーザーのアクセスキー・シークレットキーを入力し、リージョンは ap-northeast-1 を入力します。
CloudWatchAgentをインストール
引き続き、SSH接続したまま、下記コマンドでCloudWatchAgentをインストールします。
$ sudo yum install amazon-cloudwatch-agentと思ったのですが、yum:Command not foundとなってしまいyumが使用できないようです。ひとまず下記コマンドでOSを調べてみます。
$ cat /etc/issueどうやらOSがDebian GNU/Linux 11だったため、yumではなく、aptでパッケージ管理されているとのことでした。
下記サイトにOSごとのエージェントのインストールファイルのリンクがあり、それをwgetコマンドでダウンロードし、dpkgで解凍します。
.debファイルのダウンロードコマンド
wget https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.debダウンロードファイルの解凍コマンド
sudo dpkg -i -E ./amazon-cloudwatch-agent.debCloudWatchエージェントの設定
引き続きSSH接続したまま、下記コマンドでCloudWatchAgentの設定を行います。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
このコマンドでプロンプト形式で、CloudWatchエージェントの設定が始まるのですが、Lightsailの場合、下記の項目でデフォルトの回答を選択できません。
Are you using EC2 or On-Premises hosts?
Do you want to turn on StatsD daemon?
Do you want to monitor metrics from CollectD?
Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply.
Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?
Do you want to monitor any log files?
Do you want to store the config in the SSM parameter store?こちらの設定が完了すると下記パスにconfig.jsonファイルが作成されています。
CloudWatchエージェントの起動
下記コマンドでCloudWatchエージェントを起動します。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c /opt/aws/amazon-cloudwatch-agent/config.json
psコマンドでCloudWatchエージェントが動いているのを確認します。
また、これでCloudWatchにアクセスしてログが収集できてることを確認できれば完了です。
⚫︎参考サイト
https://repost.aws/ja/knowledge-center/lightsail-monitor-with-cloudwatch
今日から君もVimmer-Vimで最低限覚えておきたいコマンド-
Linuxを使っているとVimを使わざるを得ない時が多々あります。
そんな時に最低限これさえ覚えておけば大丈夫というコマンドを列挙していきます。僕は普段これで乗り切ってます。
玄人になりたい人というよりは、なぜか分からないけどVimを使わないといけないという人向けになります。
Vimでファイルを開く
vi [ファイル名]ファイルを編集する
aキーを押下するとファイル編集ができます。
ファイルの編集を終わる
編集状態でescキーを押下するとファイルの編集が終わります。
ファイルの変更を保存して終わる
ファイル編集が終わった状態で、下記コマンドを実行します。
:wq ファイルの変更を破棄する
ファイル編集が終わった状態で、下記コマンドを実行します。
:q!特定の文字列の検索
/[文字列]次の検索結果へ
nVimの難しい機能や仕様は把握してませんが、ひとまずこれで何とかVimを使用した作業ができます。
ELB(Elastic Load Balancing)ロードバランサーとは【AWS基礎】
こんにちは。かじです。
今回は、AWSのELB(Elastic Load Balancing)を解説したいと思います。
ELBとは
ELBとはElastic Load Balancingの略称で、AWSが用意しているロードバランシングのためのマネージドサービスです。
負荷分散や冗長化するために複数用意したEC2などのAWSリソースに対して、リクエストを分散させる役割があります。
ロードバランサーとは
公開していたサービスが流行りユーザー数が増えるという場面を想像しましょう。最初は数十人までの利用を想定して用意したサーバーだと、一気に数千人まで使用するユーザが増えた場合、サーバの処理性能が足りなくなってしまいます。
こういった場合に対処する方法として、サーバーの台数を増やすスケールアウトという方法が取られます。この際、サーバーの台数を増やすのはいいですが、どうやって各サーバーへのアクセスを振り分けるのでしょうか。サーバーの台数を増やすということは、その分IPアドレスが増えることになりますし、ドメインも各サーバに対応させるには複数のドメインが必要になるのではないでしょうか。
そこで使用するのがロードバランサーです。
ロードバランサーはまず、クライアントからのアクセスを全て集め、処理できるサーバーにアクセスを振り分けることを行います。
これによって、クライアントはロードバランサーに対してのみリクエストをするだけで良くなり、サーバーのIPなどを意識する必要がなくなります。
また、複数用意したサーバーのうち、一つに障害が起きてしまった場合、ロードバランサーがそのサーバーに対してリクエストを振らないようにするため、障害の影響を最小限に抑えることができます。
ロードバランサーの役割
ロードバランサーの主な役割は下記の3つが挙げられます。
1.リクエストの分散
2.SSL処理
3.不正リクエスト対策
それぞれについて解説していきます。
1.リクエストの分散
まずは、リクエストの分散です。こちらは前項までで説明したところと同じになります。
用意した複数のサーバーに対して負荷分散されるよう適切にアクセスを振り分けます。
2.SSL処理
ロードバランサーはサーバーの代わりにクライアントからのリクエストを受け付けます。その際、SSL証明書をロードバランサーに配置しておくことで、SSLの暗号化および復号化処理をロードバランサーが行ってくれます。
3.不正リクエスト対策
不正なリクエストが送られた際、Webサーバー側で検知するようなプログラムを動かすこともできますが、大変な労力がかかります。ロードバランサーを使用することで、ロードバランサーが不正なリクエストを検知して処理してくれます。
ELBが提供しているロードバランサーの種類
ALB
まずは、ALB(Application Load Balancer)です。
HTTP(S)通信によるアクセスを分散させるためのロードバランサーになります。
負荷分散に加えて、SSL処理やセッションごとに分散対象を固定化するスティッキーセッション、アクセスログの記録、URIの文字列によって分散対象を変更するコンテントベースルーティングなどがあります。
NLB
次に、NLB(Network Load Balancer)です。
NLBには基本的な分散処理機能だけが備わっており、ソケット通信など様々な通信プロトコルに対応したロードバランサーとして使用できます。
GWLB
次に、GWLB(Gateway Load Balancer)です。
GWLBは、サードパーティの仮想アプライアンスをデプロイ、スケーリング、管理できるロードバランサーで、ファイアウォール、侵入検知防止システム、などのセキュリティ製品をAWSで利用する場合に適しています。GWLBを使用することで、仮想アプライアンスの可用性を向上させ、トラフィックを効率的に制御できます。
CLB
最後にCLB(Classic Load Balancer)です。
ALBやNLBが登場する前の古いロードバランサーになります。
SSL処理やセッションごとの分散、アクセスログの記録など機能のほとんどはALBに備えられているため、新規で使用することはほとんどありません。
今回は、ここまでになります。最後まで閲覧くださり、ありがとうございました。
【DNS】CNAMEは他のレコードと共有できない-Route53を使用していない場合-
CNAMEが登録できないトラブル
こんにちは。かじです。
今回はDNSでCNAMEレコードが他のレコードと共有できない問題について書いていきたいと思います。
以前、AWSでEC2、ALBを使用したwebシステムの開発を行ったのですが、ネームサーバーは既に稼働しているAWS以外のサービスを使用していました。
その際にルートドメインに既にレコードがあるため、ALBのDNS名をCNAMEレコードに登録することができませんでした。
どうして登録できないかというと、CNAMEレコードは他のレコードと共存できないというルールのため。なぜそんなルールがあるかというと、RFCで定められてるからのようで、その先の理屈的な理由までは、分かりませんでした。
ネームサーバーがRoute53であれば、ALIASレコードを設定することでこの問題を回避できるようですが、あいにく今回使用しているネームサーバーにはそのような機能はありませんでした。
また、AレコードにALBのグローバルIPアドレスを登録するにしても、ALBは、IPアドレスが自動で変わるため、この策もダメです。
このように使用するインフラサービスが複数に跨って困難が生まれる時こそエンジニアの腕の見せ所かと思います。まあ、考えられる方法を出して提案するところまでしかできないのですが。
いくつか方法を書いていきたいと思います。
解決方法
それでは解決方法を書いていきたいと思います。シンプルなものから書いていきたいと思います。シンプルだからといっても、リーダーや関係者を説得する必要があるので骨が折れるかもしれませんが。
1.ルートドメインの使用をやめてwwwなどのサブドメインを使用する
一つ目は単純にルートドメインの使用をしないことです。ルートドメインがメール用などのレコードが登録されている場合、wwwなどWEBアプリ用のみで使用されるサブドメインを割り当てることです。
割り当てたサブドメインのCNAMEにALBのDNS名を登録することで完了するので、一番早く解決できます。
ルートドメインをどうしても使いたいという場合を除いてこれで解決します。僕のケースもこの方法で落着しました。
2.ネームサーバーをRoute53に移行しALIASレコードを使用する
続いてより面倒くさい方法としては、ドメインのネームサーバーをRoute53に移行して、ALIASレコードを変更するということです。まあ、レコードを全部入れ替えるので影響範囲や作業から変更の反映までに時間がかかり、トラブルが発生した場合は、システムにダウンタイムが発生してしまうのであまりお勧めしません。ただ、ネームサーバーを入れ替えるだけですので、後の二つに比べると、運用費用が大きく追加されることはないかと思います。もちろん既存のネームサーバーサービスによりけりですが。
3.WEBサーバーをパブリックサブネットに配置しElastic IPを使用する
続いての方法としては、WEBサーバー用のEC2をパブリックサブネットに配置してElastic IPを割り当てることが挙げられるかと思います。
割り当てたElastic IPをネームサーバーのAレコードに登録することで、解決します。
これはALBを使用しなくなるという点、またDBとWEBサーバーが共存している場合、WEBサーバーを切り分けなければいけないので、システムの構成をそもそも変える必要があります。
Elastic IPの料金については時間あたりUSD0.005で月720時間あたり、USD3.6となりますが、もし、DBサーバーとWEBサーバーを切り分けるとなると、追加のインスタンス料金もかかってしまいます。
また、ALBであれば簡単に設定できたhttpsの設定も少しの手間が必要です。一応下記にElastic IPでhttps通信を設定する方法を紹介しておきます。
https://blog.denet.co.jp/acm-ssl-apache/
4.Network Load BalancerかGlobal Acceleratorを使用してグローバルIPを固定する
最後は、ALBの前にNetwork Load BalancerかGlobal Acceleratorを配置して固定されたIPアドレスを使用可能にする方法です。
料金は、ALB+NLBの構成であれば、場合時間あたり「USD0.0225(ALB)+ USD 0.0225(NLB)」、Global Acceleratorの構成であれば、時間あたり「USD0.0225(ALB) + USD 0.025(Global Accelerator)」ほどかかってしまいます。それぞれ、月720時間に換算するとUSD32.4とUSD34.2になります。
今回は、CNAMEを登録できない現象について、Route53を使用していない場合の解決方法を述べてみました。皆様に参考になれば幸いです。
セキュリティグループとは【AWS基礎】
こんにちは、かじです。
今回はAWSのセキュリティグループについて解説したいと思います。
セキュリティグループとは
AWS上にEC2インスタンスなどのリソースを構築した後、WEBサーバーであれば、HTTP通信だけを許可したいというように、リソースごとに通信を制限したい場合があります。
この通信を許可する仕組みをセキュリティグループといいます。
セキュリティグループでは、通信プロトコルや通信するポート、接続元IPアドレスによって許可する通信を選択することができます。
セキュリティグループで選択していない通信方法ではAWSリソースに対して接続することができません。
ポートは、HTTPでは80、HTTPSでは443といように、各通信プロトコルによって通信できるポート番号を制限することができます。
最後にIPアドレスについてです。これは接続されるIPアドレスを指定する際に使用します。踏み台サーバーからのSSHのみを制限する時などに使用することで他のマシンからのアクセスを制限することができます。
ネットワークACLとは
また、セキュリティグループは各インスタンスに対して選択しますが、サブネットに対して設定するネットワークACLというものもあります。二箇所で通信の制限をかけることで二重管理となってしまうことがあるので、基本はセキュリティグループ、運用上必要な場合のみにネットワークACLを使用するなどのルールを定めて使い分けたほうが良いでしょう。
ノーコード/ローコードをどうやって使っていくか
仕事柄、HP制作、システム開発でノーコードやローコードツールを使用する場面があり、今回はその肌感を書いていけたらと思う。
意外とコーディングの知識が必要
ノーコードにもローコードにもいくつかの誤解があるように感じた。そのうちの一つが、プログラミングの知識が意外と必要だということ。
ノーコードツールを使用したHP制作では、確かに簡単なHPを作成することは実感できた。しかし、GUI操作だけで対応できないことは勿論、少しテンプレートと異なるデザインをしたいとなったら、HTMLとCSS的に考えて実装しなければいけない。
HTML弱者である僕も初めて知ったのだが、buttonタグにaタグを適用することはできないらしい。非エンジニアの人から見れば、aタグもボタンもクリックできるんだから同じだろうと思うだろうが、ツール的にはできないものは出来ないらしい。
まあ、HTMLを生成するんだからHTMLに忠実なのは仕方がないか。
ローコードだって、for文の書き方や変数の考え方、データの型についてある程度の知識が必要だし、DB設計だってできないときちんと使えるシステムを作るのは難しい。こういうところが意外とエンジニア的な素養が必要であると感じた点である。
工数削減
とはいえ、開発や制作の工数の削減は顕著だ。フロントエンド難民の僕でも数日で人に見せられるものを作れたし、シンプルであればシステムもRPAツールの開発もあっという間である。
エンジニアはコーディングしたいエゴと魔法のようなツールという言葉に惑わされて、「あれ？こんなこともできない。」なんて文句を言ってしまうが、お客さんからしたら、エンジニアの戸惑いは関係なく、安いだけでメリットだろう。
セキュリティの管理も楽
自分でサーバーを管理しないのであれば、セキュリティを管理する必要も少なくなる。多くの場合ツールを提供している会社の管理範囲にセキュリティが含まれるから、そういうところは考えなくてもいい。つまるところ、保守コストも下がる。
プラットフォーム特有の技術的な問題
工数を削減できる一方で、ノーコード・ローコードは、やはり特定のプラットフォームで動くツールであることは間違いない。
つまり、ローコードの数少ないコーディング部分が通常の言語とは仕様が異なるとか、一般的なデータベースではないために、結合がしにくいなどは感じた問題点である。
また、機能的な制約もあり、CMSで動画を使えないとか、ネットワークの制約を解決できないということはあり得る。
ノーコード・ローコード技術との向き合い方
最後にノーコード・ローコードとの向き合い方を考えて終わりたいと思う。
クライアントワークの場合、予算と仕様の問題に限る。予算は、開発工数がどの程度抑えられるのか、運用費用はどの程度かかるのか。そのトレードオフがプラスに転じるのならノーコード・ローコードの使用は大いに視野に入れていいだろう。
次に仕様を達成できるか。ネットワーク要件や他システムとの連携などの機能が実現できるのかが鍵である。要件定義の中で必要機能、システムの将来展望も引き出した要件を洗い出し、それらをプラットフォーム上で構築することができるのかを調査する。その調査結果を元にツールの使用を検討することは必須である。何でもかんでもできるわけではないということは頭に入れておく必要がある。
また、長期的に見た時に二つの懸念点があると思っている。
一つ目は保守面の問題である。プラットフォームの状況が運用保守に関わってくるという面である。極端ではあるが、プラットフォームの運営会社が破綻してサービスが止まってしまったら、システムもWEBページも停止してしまう。そこまで極端でなくても、アップデートが起きたときに何もしてなくても動作が変わってしまうみたいなことも考えられる。
まあ、レンタルサーバーでもクラウドでも会社が潰れる可能性なんてゼロじゃないんだから、ノーコード・ローコードに限った話ではないし、アップデートだってなるべく動作に影響のないように開発しているだろうから、考える必要はないだろとかあるかもしれない。
どちらにせよ、サーバーやプラットフォームを自分たちで管理している訳ではないので、外的要因に左右される部分は大きくなる。
二つ目はプログラマが育たない問題である。
ノーコード・ローコードばかりでスクラッチで開発するプログラマが育たない問題みたいなものは考えられる。また、プラットフォームを利用している以上、ミドルウェア以下に対する知識や経験が付かないのも問題としてある。アウトプットが出てる以上、ビジネス目線価格が安く、プラスしかないと思うかもしれないけど、メンバーの技術的な土台を築くことができないことは、長期的に見たらネガティブに働くことは全然あり得る話だと思っている。
これらの問題とどう向き合っていくかが、ノーコード・ローコード問題のカギになるかと考えている。
今回はここらへんにしたいと思う。