2020年7月

AWS Lambdaを使った外形監視

福岡拠点の野田です。
AWSを使ったサーバー構築が最近増えてきました。今回は、AWS Lambdaを使った外形監視の方法を紹介しようと思います。

AWS Lambdaは、軽量なアプリケーションを動作するときに活躍するサービスです。5分おきのバッチサービス、管理画面でのSSRサービスなど、常に常駐しておく必要がないプログラムを動かすのに適しています。今回紹介する監視系のバッチもLambdaと相性のよいアプリケーションの１つとして考えています。

AWS Lambdaを使った外形監視の作成を以下の手順ですすめていきます。

関数の作成
関数コードの作成
トリガーの追加

関数の作成

「１から作成」を選択します。関数名は「check_http」のような名前を付けます。ランタイムは、javascriptサーバーの「node.js12.x」を選択して関数を作成します。

アクセス権限については、「基本的な Lambda アクセス権限で新しいロールを作成」を選ぶとAmazon CloudWatch Logsの権限が付与されるので、これを選びます。

関数コードの作成

index.jsに以下をコピペします。

[crayon-673ed31c76b3b282194833  ]function getNativeRequest(url) {
  const https = require('https')
  const options = {timeout: 1000};
  const promise = new Promise(function(resolve, reject) {
    const req = https.get(url, options, (res) => {
        resolve(res.statusCode)
      }).on('error', (e) => {
        reject(Error(e))
      }).on('timeout', () => {
        reject("Timeout Error")
      })
  })
  return promise
};

exports.handler = async (event, context, callback) => {
  const url = process.env['ENV_URL'];
  return getNativeRequest(url);
};

[crayon-673ed31c76b3b282194833 ]function getNativeRequest(url) {

const https = require('https')

const options = {timeout: 1000};

const promise = new Promise(function(resolve, reject) {

const req = https.get(url, options, (res) => {

resolve(res.statusCode)

}).on('error', (e) => {

reject(Error(e))

}).on('timeout', () => {

reject("Timeout Error")

})

return promise

};

exports.handler = async (event, context, callback) => {

const url = process.env['ENV_URL'];

return getNativeRequest(url);

};

[/crayon]

ページ末尾の環境変数に以下のような監視対象URLを指定します。

ENV_URL https://(監視対象URL)

トリガーの追加

EventBridge(CloudWatchEvents)を追加します。
ルールは、新規ルールでルール名を「every5min」を指定します。ルールタイプはスケジュール式で以下を設定します。

説明: ５分毎
イベントバス: default
スケジュール式: cron(0/5 * * * ? *)

あとは、CloudWatch側で以下のようなアラートルールを設定することで監視完了です。

5 分内の1データポイントのErrors > 0

1	5 分内の1データポイントのErrors > 0

Lambdaはいろいろな使い方ができると思うので、引き続き使っていこうと思います。

[bug]マルチプロセスでlog4netのファイルローテーション時に一部ログが欠損して困った

福岡の香月です。

log4netのRollingFileAppenderを使って日付で出力ファイルが切り替わる設定をしていたところ、日付が変わって新しいファイルへの出力が始まると先頭に出力されるであろうログがなぜか出力されない現象に遭遇しました。
設定はこうです。
複数のプロセスで同じ設定を用いて、同じファイルに対してログ出力します。

[crayon-673ed31c76eb7608034082  ]<appender name="SystemLogAppender" type="log4net.Appender.RollingFileAppender">
  <file value="log/system.log" />
  <appendToFile value="true" />
  <datePattern value="_yyyyMMdd" />
  <preserveLogFileNameExtension value="true" />
  <staticLogFileName value="false" />
  <lockingModel type="log4net.Appender.FileAppender+InterProcessLock" />
  <encoding value="Shift_JIS"/>
  <maxSizeRollBackups value="-1" />
  <maximumFileSize value="2GB" />
  <layout type="log4net.Layout.PatternLayout">
    <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss.fff} %-5p %m%n"/>
  </layout>
</appender>

[crayon-673ed31c76eb7608034082 ]<appender name="SystemLogAppender" type="log4net.Appender.RollingFileAppender">

</layout>

</appender>

[/crayon]

AppenderはRollingFileAppenderを指定しています。複数プロセスで使用するため、lockingModelはInterProcessLockを指定します。これによりファイルストリームを開きっぱなしにして、mutexで排他制御しながら末端にシークし書き込みを行うことで、複数プロセスから効率的にログ出力を行ってくれます。
複数プロセスから使う場合はこれ以外にもMinimalLockを指定できますが、書き込むたびにファイルのオープンクローズを実施するため速度が求められる場合は不向きでしょう。さらに複数プロセスからの出力が同時に走った場合、片方はオープンできないためログが出力されません。

この設定でビルドし、業務終わりにアプリを起動して一晩中実行させ、翌朝出社して確認しても日付が変わった後のログの内容が足りませんでした。
最初はlog4netの使い方が悪いのか、自分のプログラムにバグがあるのかさんざん悩んだんですがさっぱりわからない。トレース用に埋め込んだログも当然のように出ていないのでどうしたものかと思いました。

しかし、プロセスが1つの場合はちゃんと期待通りのログが出ていました。問題があるのは複数プロセスの場合だけだったのです。

そこでlog4netのロジックを確認することにしました。幸いなことにソースはこちらから取得できます。
https://github.com/apache/logging-log4net
すると、ファイルが切り替わったあとは最後に書き込んだプロセスのログが先頭に来て、それ以前のログが破棄される作りになっていたのです。

少しずつソースを見てみましょう。今回使っているのはRollingFileAppenderです。日付が変わるときにファイルを切り替える部分は、RollOverTime()という関数であることがわかりました。こうなっています。
https://github.com/apache/logging-log4net/blob/master/src/Appender/RollingFileAppender.cs

[crayon-673ed31c76ebb366983441  ]protected void RollOverTime(bool fileIsOpen) 
{
    ：
    ：
    if (fileIsOpen)
    {
        // This will also close the file. This is OK since multiple close operations are safe.
        SafeOpenFile(m_baseFileName, false);
    }
}

[crayon-673ed31c76ebb366983441 ]protected void RollOverTime(bool fileIsOpen)

{

：

if (fileIsOpen)

{

// This will also close the file. This is OK since multiple close operations are safe.

SafeOpenFile(m_baseFileName, false);

}

[/crayon]

ふむふむ、SafeOpenFile()で新しいファイルをオープンしに行くわけね。そして第二引数がfalseと。そしてSaveOpenFile()の実態はベースクラスFileAppenderにありました。
https://github.com/apache/logging-log4net/blob/master/src/Appender/FileAppender.cs
ここから次の順番で呼び出されていきます。

RollingFileAppender.OpenFile()
FileAppender.OpenFile()
FileAppender.InterProcessLock.OpenFile()
FileAppender.LockingModelBase.CreateStream()

[crayon-673ed31c76ebe657993948  ]protected Stream CreateStream(string filename, bool append, FileShare fileShare)
{
	using (CurrentAppender.SecurityContext.Impersonate(this))
	{
		// Ensure that the directory structure exists
		string directoryFullName = Path.GetDirectoryName(filename);

		// Only create the directory if it does not exist
		// doing this check here resolves some permissions failures
		if (!Directory.Exists(directoryFullName))
		{
			Directory.CreateDirectory(directoryFullName);
		}

		FileMode fileOpenMode = append ? FileMode.Append : FileMode.Create;
		return new FileStream(filename, fileOpenMode, FileAccess.Write, fileShare);
	}
}

[crayon-673ed31c76ebe657993948 ]protected Stream CreateStream(string filename, bool append, FileShare fileShare)

{

using (CurrentAppender.SecurityContext.Impersonate(this))

{

// Ensure that the directory structure exists

string directoryFullName = Path.GetDirectoryName(filename);

// Only create the directory if it does not exist

// doing this check here resolves some permissions failures

if (!Directory.Exists(directoryFullName))

{

Directory.CreateDirectory(directoryFullName);

}

FileMode fileOpenMode = append ? FileMode.Append : FileMode.Create;

return new FileStream(filename, fileOpenMode, FileAccess.Write, fileShare);

}

[/crayon]

ここでSafeOpenFile()の第二引数で指定されたfalseは、CreateStreamのappendに代入されていることがわかりました。この場合FileMode.Createが指定され、FileStreamインスタンスが作成されます。
ではこのFileMode.Createはどのような動きをするかというと、

オペレーティングシステムが新しいファイルを作成することを指定します。ファイルが既に存在する場合は上書きされます。これには Write 許可が必要です。
FileMode.Create は、ファイルが存在しない場合は CreateNew を使用した要求、ファイルが存在する場合は Truncate を使用した要求と等価です。
https://docs.microsoft.com/ja-jp/dotnet/api/system.io.filemode?view=netcore-3.1

複数のプロセスでログ出力を行う場合、FileStreamを最後に作成するプロセスによりそれまでのプロセスが作成したログファイルの中身がTruncateされて、つまり削除されてしまうわけです。
発生している現象とも合致するのでこれが問題であることを確信しました。

対応するためにはRollingFileAppender.RollOverTime()から呼んでるSafeOpenFile()の第二引数をtrueに知ればよいわけです。実際に修正して確認してみると、見事欠損することなく必要なログが出力されていました。
めでたしめでたし。

なお、SafeOpenFile()はRollingFileAppender.RollOverSize()内からも呼び出しているのでここも忘れずにtrueに変更しましょう。

S3+CloudFront+Route 53を使った静的コンテンツ配信 Part 2 （lambda@edge編）

福岡拠点の野田です。

前回、S3を使った静的コンテンツ配信を実現しましたが、ちょっとカッコ悪い点がありました。

ドメイン直下については、 Default Root Object 設定すると https://サイト名/でアクセスしたときindex.html を参照するようにできます。ただし、サブディレクトリ配下はDefault Root Objectの設定が効きません。サブディレクトリ配下で/news/とアクセスしたとき、/news/index.htmlを参照するためにはlambda@edgeを使う必要があります。

/で終わるuriの場合に/index.htmlを参照する設定について、今回は以下の流れで設定を行います。

lambdaを追加
CloudFrontで使えるようにIAMを修正
lambdaにトリガーを追加し、CloudFrontと関連付け

lambdaを追加

リージョンus-east-1のlambda画面から関数を追加します。ほかのリージョンではCloudFrontへのトリガーを作成できないため、正しいリージョンが選択されているか確認してください。

https://console.aws.amazon.com/lambda/home?region=us-east-1

lambdaは１から作る形で進めます。

・関数名：subdir-redirect （適宜適当な名前を設定してください）
・ランタイム：nodejs (バージョンはデフォルトでOK）
・アクセス権限：AWSポリシーテンプレートから新しいロールを作成
・ロール名：cloudfront-lambda （適宜適当な名前を設定してください）
・ポリシーテンプレート：基本的なlambda@edgeのアクセス権限

関数詳細ページが表示されるので、関数コードに以下を追加します。

[crayon-673ed31c770e3990054985  ]'use strict';
exports.handler = (event, context, callback) => {
    var request = event.Records[0].cf.request;
    request.uri = request.uri.replace(/\/$/, '\/index.html');
    return callback(null, request);
};

[crayon-673ed31c770e3990054985 ]'use strict';

exports.handler = (event, context, callback) => {

var request = event.Records[0].cf.request;

request.uri = request.uri.replace(/\/$/, '\/index.html');

return callback(null, request);

};

[/crayon]

画面右上の「保存」を押下してコードを保存します。

CloudFrontで使えるようにIAMを修正

そのままでは使うことができないため、関数詳細ページ「アクセス権限」のタブを選択します。実行ロール「 cloudfront-lambda 」を編集し、末尾の「 IAM コンソールで cloudfront-lambda ロールを表示します。」のリンクをクリックします。

ロールの詳細ページから「信頼関係」のタブをクリックします。「信頼関係の編集」ボタンを押下して、以下のようにedgelambdaの設定を追加します。

[crayon-673ed31c770e7150709998  ]{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "lambda.amazonaws.com",
          "edgelambda.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

[crayon-673ed31c770e7150709998 ]{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Principal": {

"Service": [

"lambda.amazonaws.com",

"edgelambda.amazonaws.com"

]

"Action": "sts:AssumeRole"

}

]

}

[/crayon]

これにより信頼されたエンティティにedgelambdaが追加されます。

信頼されたエンティティ
ID プロバイダー lambda.amazonaws.com
ID プロバイダー edgelambda.amazonaws.com

続いて「アクセス権限」のタブに再度戻ります。＋インラインポリシーの追加から以下のポリシーを追加します。

Lambda: GetFunction, EnableReplication (対象リソースは、先ほど登録したsubdir-redirect lambda のARNを指定)
IAM: CreateServiceLinkedRole（対象リソースはすべて）
CloudFront: UpdateDistribution（対象リソースは、展開するCloudFrontのARNを指定）

ここまでやってようやくlambda@edgeが使えるようになります。

lambdaにトリガーを追加し、CloudFrontと関連付け

仕上げにlambdaの関数詳細画面に戻ります。画面上の「アクション」から新しいバージョンを発行します。コメントは必要あれば適宜入力してください。

そののちにデザイナーから「トリガー」を追加します。トリガーの種類は、CloudFrontを選択します。ここでCloudFrontが選択できない場合はlambdaのリージョンが間違っていますので、最初からやり直してください。設定はデフォルトのままで以下のチェックボックスにチェックを入れます。

[crayon-673ed31c770ec028473984  ] Lambda@Edge へのデプロイを確認 
関数のこのバージョンが上記のトリガーと関連付けられ、利用可能なすべての AWS リージョン間でレプリケートされることに同意します。

1 2	[crayon-673ed31c770ec028473984 ] Lambda@Edge へのデプロイを確認関数のこのバージョンが上記のトリガーと関連付けられ、利用可能なすべての AWS リージョン間でレプリケートされることに同意します。

[/crayon]

追加ボタンを押下するとCloudFrontへの更新が入ります。Distributionの更新が終わるまでしばし待つと、晴れてサブディレクトリのリダイレクト処理を利用することができるようになります。

まとめ

lambdaというと単機能のAPIや軽量サーバーとして使うイメージが強いですが、実はいろいろなところに組み込めます。lambda@edgeを利用することでCloudFrontに対してヘッダーのカスタマイズ、 BASIC認証など多岐にわたって処理を組み込むことができます。静的コンテンツに対してちょっとした動的処理を行いたいな、というときはlambda@edgeの出番です。是非ご活用いただければと思います。

面倒なところもありますが、ひと手間かけるといろいろなことができるのがAWSの良いところ。いろいろエンジニアとしていろいろHackしていければと思います。

S3+CloudFront+Route 53を使った静的コンテンツ配信

福岡拠点の野田です。

WordPressで運用していた個人サイトをメンテしなくなったので、S3とCloudFrontとRoute 53を使って静的コンテンツ配信方式に切り替えてみました。手順の大きな流れは以下のようになります。

S3にコンテンツを配置
CloudFrontを設定
Route53でCloudFrontへ振り分け

S3 にコンテンツを配置

まずは、wget で既存サイトを取得します。

[crayon-673ed31c772c3624349689  ]wget --mirror --page-requisites --span-hosts --quiet --show-progress --no-parent --convert-links --no-host-directories --adjust-extension --execute robots=off （サイトURL）

1	[crayon-673ed31c772c3624349689 ]wget --mirror --page-requisites --span-hosts --quiet --show-progress --no-parent --convert-links --no-host-directories --adjust-extension --execute robots=off （サイトURL）

[/crayon]

日本向けに配信することを考え、 S3 の東京リージョンにて新規バケットを作成して、上記取得したファイルを配置します。

S3における設定ですが、アクセス権限の設定を行います。静的コンテンツとして公開するため、以下のバケットポリシーのブロックをオフにすることで外部からのアクセスを行えるようにします。

新規のパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックするオフ
任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックするオフ

バケットポリシーは、以下のようなCloudFrontからの接続を許可する設定を行いますが、CloudFront側から設定ができるため、ひとまずスキップで大丈夫です。

[crayon-673ed31c772c7262161000  ]{
     "Version": "2012-10-17",
     "Statement": [
         {
             "Sid": "2",
             "Effect": "Allow",
             "Principal": {
                 "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity OAIのID"
             },
             "Action": "s3:GetObject",
             "Resource": "arn:aws:s3:::バケット名/"
         }
     ]
 }

[crayon-673ed31c772c7262161000 ]{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "2",

"Effect": "Allow",

"Principal": {

"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity OAIのID"

"Action": "s3:GetObject",

"Resource": "arn:aws:s3:::バケット名/"

}

]

}

[/crayon]

CloudFrontを設定

Create DistributionでCDNを新規作成します。

Web/RTMPの選択でWebを選択
Origin Domain NameにS3のバケットを選択
Origin Pathは空欄でOK
Origin IDは任意のIDを設定（S3-バケット名みたいな感じで設定しました)
Restrict Bucket Accessは、YES
Origin Access Identityは、 Create a New Identity。
Grant Read Permissions on Bucketは Yes, Update Bucket Policy （これが先ほどのS3バケットポリシーに反映されますので、一応S3側でも設定されているか確認）
Viewer Protocol Policyは、Redirect HTTP to HTTPS (httpからhttpsリダイレクト)
Allowed HTTP Methodsは、GET/HEADのみで対応（CORSを考えるとOPTIONSまでやってもいいかもしれません）
Compress Objects Automaticallyは、true（圧縮化。転送量削減）
Price Classはベストパフォーマンス
AWS WAF Web ACLは、None
Alternate Domain Namesは割り当てるドメイン名を改行区切りで入力。
証明書については、独自ドメインで割り当てる場合、ACMに登録したものを選択。
残りはデフォルトで登録

Distribution作成後、 GeneralタブでEditボタンを押下して、以下を設定します。

Default Root Objectにindex.htmlを設定

続いて Restrictionsタブを選択して、GeoRestrictionをEditします。

今回は、日本のみを対象とします。全世界を対象とするとコストと直結します。1日1000円以上かかってもいい！どんな攻撃もどんとこい！という方以外は、対象を絞ったほうが良いと思います（私もこれで当初1日放置して1000円かかってしまい冷や汗、急遽制限を追加しました）。

Route53でCloudFrontへ振り分け

仕上げにRoute53からCloudFrontへ振り分けします。A(IPv4アドレス)およびAAAA(IPv6アドレス）のエイリアス指定でCloudFrontにつなげることができます。

まとめ

Cloudは設定をミスると高額な請求が発生してしまうリスクはありますが、うまく使えば個人で使っても安く運用することができます。最近では予算設定や請求が高額になりそうなときにアラートも出せる機能もありますので、そうしたものを組み合わせて、安全に運用すると良いと思います。先月からの運用の感じだとアクセス数次第なところがありますが、100円～300円/月ぐらいで運用できそうな感じでした。

初心者にはおすすめはしませんが、興味ある方は是非チャレンジしてみてください。

2020年7月
月	火	水	木	金	土	日
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

関数の作成

関数コードの作成

トリガーの 追加

トリガーの追加