インフラ・サーバー運用

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のアクセス権限

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

'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);
};

'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);

};

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

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

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

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

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

{

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

"Statement": [

{

"Effect": "Allow",

"Principal": {

"Service": [

"lambda.amazonaws.com",

"edgelambda.amazonaws.com"

]

"Action": "sts:AssumeRole"

}

]

}

これにより信頼されたエンティティに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のリージョンが間違っていますので、最初からやり直してください。設定はデフォルトのままで以下のチェックボックスにチェックを入れます。

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

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

追加ボタンを押下すると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 で既存サイトを取得します。

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

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

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

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

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

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

{
     "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:::バケット名/"
         }
     ]
 }

{

"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:::バケット名/"

}

]

}

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円/月ぐらいで運用できそうな感じでした。

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

AWSでインスタンスを停止し、再起動した時にパブリックIPが割り振られない場合

AWS特訓中の宮里です。

AWSでインスタンスを作成したときに、少し困った現象があったため情報共有したいと思います。

AWSで作成したインスタンスを一旦停止後、ネットワークインターフェイスを追加し、再起動した後にパブリックIPが割り振られない現象が発生しました。

？？？？？となりながら、再起動を何度か試すもパブリックIPは復活せず。
作成したばかりのインスタンスだったので、インスタンスを一から作成し直し、特に問題は起こりませんでした。
その後、気になったので原因を調べてみると、AWS公式のドキュメントに今回の現象の解答がありました。

下記、公式のドキュメントから一部引用します。

手動でパブリック IP アドレスをインスタンスに関連付けること、また、手動でインスタンスから割り当て解除することはできません。場合によって、パブリック IP アドレスはインスタンスから解放されたり、新しいインスタンスに割り当てられたりします。
インスタンスが停止または終了されると、インスタンスのパブリック IP アドレスは解放されます。停止していたインスタンスが再起動されると、そのインスタンスには新しいパブリック IP アドレスが送信されます。
VPC 内のインスタンスのパブリック IP アドレスが既に解放されている場合には、複数のネットワークインターフェイスがインスタンスにアタッチされていると、インスタンスに新しいパブリック IP アドレスは送信されません。

出典:
AWS ドキュメント「パブリック IPv4 アドレスと外部 DNS ホスト名」

インスタンスを再起動するときは、プライマリENI以外はインスタンスにアタッチしてはいけないということでした。。。

少しづつ身につけていきたいと思います。

AWSのタイムゾーン設定でハマった件

福岡拠点の宮里です。
先日、アパッチのアクセスログをアーカイブして一定期間保存する作業を行っていたのですが、

apache-loggenでダミーアクセスログの生成

ログを確認していると、何か違和感が…

|02/May/2018:09:24:59 +0000|

私「あれ？もう出社して9時間は経ってて、もう今日も終わっちまうのかなぁって気がしていたけど」

心の中の金子賢「バカヤロー、まだ始まってもいねーよ」

サーバー時刻をUTCからJSTへ変更

あれあれあれと心を鎮めながら、サーバーに設定されているタイムゾーンを確認してみると、

strings /etc/localtime

#出力結果
TZif2
TZif2
UTC0 #←これ

strings /etc/localtime

#出力結果

TZif2

UTC0 #←これ

このサーバーのタイムゾーンはUTC。
このままだとなにかと不都合です。
心臓にもわるいので、JST時間帯へ変更したいと思います。

sysconfigディレクトリの設定ファイル(clock)からタイムゾーンを修正します。
ひとまずバックアップ取って、

cp /etc/sysconfig/clock{,.orig}

#/etc/sysconfig/clockの修正
vi /etc/sysconfig/clock

#下記に追記修正
ZONE="Asia/Tokyo"
UTC=false

cp /etc/sysconfig/clock{,.orig}

#/etc/sysconfig/clockの修正

vi /etc/sysconfig/clock

#下記に追記修正

ZONE="Asia/Tokyo"

UTC=false

シンボリックリンクの向き先Asia/Tokyoへ変更します。

ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

#確認
ls -l /etc/localtime
/etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo

#設定変更した時刻を確認
strings /etc/localtime

#出力結果
TZif2
TZif2
JST-9 #←これ

ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

#確認

ls -l /etc/localtime

/etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo

#設定変更した時刻を確認

strings /etc/localtime

#出力結果

TZif2

JST-9 #←これ

サーバーのタイムゾーンがUTCからJSTに変わりました。

これでひと安心かと思いきや、
この作業を行う前にすでに記録されているログの時刻をJSTに修正しないと何かと収まりがわるいです。
なので、USTで記録されているログをJSTへと変換するスクリプトを作りたいと思います。

既に出力されているログの時刻をJSTへ修正

スクリプトは、サーバーに標準でインストールされているpythonで作成してライブラリをひとつだけ追加します。

pytzの取得

cd /適当なディレクトリ/

wget https://files.pythonhosted.org/packages/10/76/52efda4ef98e7544321fd8d5d512e11739c1df18b0649551aeccfb1c8376/pytz-2018.4.tar.gz

tar zxvf pytz-2018.4.tar.gz
cd pytz-2018.4
# 解凍したディレクトリから本体をコピー
cp pytz-2018.4/pytz /作業ディレクトリ/

cd /適当なディレクトリ/

wget https://files.pythonhosted.org/packages/10/76/52efda4ef98e7544321fd8d5d512e11739c1df18b0649551aeccfb1c8376/pytz-2018.4.tar.gz

tar zxvf pytz-2018.4.tar.gz

cd pytz-2018.4

# 解凍したディレクトリから本体をコピー

cp pytz-2018.4/pytz /作業ディレクトリ/

JSTへ変換するスクリプト
changeJst.py

# /usr/bin/python
# coding: utf-8
import sys
import os
import shutil
import re
import datetime
import pytz

#ディレクトリへのパス
logDirPath = '/ログのディレクトリパス/'

#正規表現
#パスにマッチ
fileNamePtn = '(access|error)_log\.[0-9]{8}$'

#ファイル名にマッチ
fileName_ptn = '.*fileName.*(access|error)_log\.[0-9]{8}$'

#access_logにマッチさせる
accsNamePtn = 'access_log\.[0-9]{8}$'
#error_logにマッチさせる
errNamePtn = 'error_log\.[0-9]{8}$'

#アクセスログ内のUTC時刻マッチ
#例:[22/May/2018:08:21:01 +0000]
accs_ptn = '[0-9]{2}/\D{3}/[0-9]{4}:[0-9]{2}:[0-9]{2}:[0-9]{2}\s\+[0-9]{4}'

#実はJST⁇の行のチェック
accs_ptn_jst = '[0-9]{2}/\D{3}/[0-9]{4}:[0-9]{2}:[0-9]{2}:[0-9]{2}\s\+0900'

#エラーログの時刻にマッチ
#例:[Tue Jun 07 15:34:25.126709 2670]
error_ptn = '\D{3}\s\D{3}\s[0-9]{2}\s[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{6}\s2[0-9]{3}'

def changeJST(string):
    result = ""
    jst_time = ""
    #もしJST時刻ならスルー
    if re.search(accs_ptn_jst, string):
      return None
    #アクセスログにマッチ
    elif re.search(accs_ptn, string):
      ff = re.search(accs_ptn, string)
      utc = []
      #月
      ffDec = re.search('/\D{3}', ff.group(0))
      utc.append(ffDec.group(0)[1:])
      #日
      ffDec = re.search('[0-9]{2}', ff.group(0))
      utc.append(ffDec.group(0))
      #時間
      ffDec = re.search(':[0-9]{2}:[0-9]{2}:[0-9]{2}', ff.group(0))
      utc.append(ffDec.group(0)[1:])
      #時差
      ffDec = re.search('\+[0-9]{4}', ff.group(0))
      utc.append(ffDec.group(0))
      #年
      ffDec = re.search('2[0-9]{3}', ff.group(0))
      utc.append(ffDec.group(0))
      #並べ替え
      #形式:Nov 29 06:08:08 +0000 2006
      result = "%s %s %s %s %s" % (utc[0], utc[1], utc[2], utc[3], utc[4])
      utcDate = datetime.datetime.strptime(result, '%b %d %H:%M:%S +0000 %Y')
      jstTimezone = pytz.timezone('Asia/Tokyo')
      #Asia/Tokyoへ変換後、元のログフォーマットへ戻す
      jst_time = jstTimezone.fromutc(utcDate)
      #形式[07/Jun/2018:01:47:12 +0900]
      jst_time = jst_time.strftime('%d/%b/%Y:%X %z')
      return jst_time
    #エラーログにマッチ
    elif re.search(error_ptn, string):
      ff = re.search(error_ptn, string)
      utc = []
      #曜日
      ffDec = re.search('^\D{3}\s', ff.group(0))
      utc.append(ffDec.group(0)[:-1])
      #月
      ffDec = re.search('\s\D{3}\s', ff.group(0))
      utc.append(ffDec.group(0)[1:][:-1])
      #日
      ffDec = re.search('\s[0-9]{2}\s', ff.group(0))
      utc.append(ffDec.group(0)[1:][:-1])
      #時間
      ffDec = re.search('\s[0-9]{2}:[0-9]{2}:[0-9]{2}', ff.group(0))
      utc.append(ffDec.group(0)[1:])
      #id
      ffDec = re.search('\.[0-9]{6}', ff.group(0))
      utc.append(ffDec.group(0))
      #年
      ffDec = re.search('\s2[0-9]{3}', ff.group(0))
      utc.append(ffDec.group(0)[1:])
      
      #エラーログにマッチ
      #配列の中身の例:['Thu', 'Jun', '07', '06:35:13', '.378829', '2018']
      #並べ替え
      #形式:Nov 29 06:08:08 +0000 2006
      result = "%s %s %s +0000 %s" % (utc[1], utc[2], utc[3], utc[5])
      utcDate = datetime.datetime.strptime(result, '%b %d %H:%M:%S +0000 %Y')
      jstTimezone = pytz.timezone('Asia/Tokyo')
      #Asia/Tokyoへ変換後、元のログフォーマットへ戻す
      jst_error = jstTimezone.fromutc(utcDate)
      #形式:[Tue Jun 05 07:44:15.465239 2018]
      #Thu Jun 07 15:35:13 2018
      jst_time = jst_error.strftime('%a %b %d ')
      jst_time += jst_error.strftime('%X')
      jst_time += utc[4]
      jst_time += jst_error.strftime(' %Y')
      return jst_time
    else:
        return None

#標準入力から読込
for line in sys.stdin:    
    #オリジナルログの保存ディレクトリの作成
    #保存ディレクトリの存在チェック後、存在しなければmkdir
    if os.path.isdir("%sfileName" % logDirPath) is not True:
     os.makedirs("%sfileName" % logDirPath)
    #行末の改行を削除
    line = line.rstrip()
    #Readでオープン
    file = open(line, "r")
    newFileName = ""
    #念のためファイルの存在チェック後、
    #読み込んだファイルを保存ディレクトリへ移動
    if os.path.exists(line):
      fileName = re.search(fileNamePtn, line)
      fName = fileName.group(0)
      if re.search(fileName_ptn, line):
        fPath = "%sfileName/%s" % (logDirPath, fName)
        shutil.move(line, fPath)

      #読み込んだファイルを1行ずつ処理
      for row in file:
        #UTCからJSTへ変換する関数。JSTに変換された日付の文字列が返ってくる
        toJst = changeJST(row)
        utcToJst = ""
        if toJst is not None:
          if re.search(accsNamePtn, line):
            utcToJst = re.sub(accs_ptn, toJst, row)
          elif re.search(errNamePtn, line):
            utcToJst = re.sub(error_ptn, toJst, row)
          #新規ファイルへの書き込み。無限ループ回避の名前変更
          newFileName = line + ".log"
          newfile = open(newFileName, "a")
          newfile.write(utcToJst)
          newfile.close()
    file.close()
    #元のファイル名へ戻す
    if os.path.isfile(newFileName):      
      os.rename(newFileName, line)
    else:
      #ファイル全体で修正が無かったときに保存ディレクトリにmvしたファイルを戻す
      if re.search(fileName_ptn, line):
        fPath = "%sfileName/%s" % (logDirPath, fName)
        shutil.copy2(fPath, line)

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

# /usr/bin/python

# coding: utf-8

import sys

import os

import shutil

import re

import datetime

import pytz

#ディレクトリへのパス

logDirPath = '/ログのディレクトリパス/'

#正規表現

#パスにマッチ

fileNamePtn = '(access|error)_log\.[0-9]{8}$'

#ファイル名にマッチ

fileName_ptn = '.*fileName.*(access|error)_log\.[0-9]{8}$'

#access_logにマッチさせる

accsNamePtn = 'access_log\.[0-9]{8}$'

#error_logにマッチさせる

errNamePtn = 'error_log\.[0-9]{8}$'

#アクセスログ内のUTC時刻マッチ

#例:[22/May/2018:08:21:01 +0000]

accs_ptn = '[0-9]{2}/\D{3}/[0-9]{4}:[0-9]{2}:[0-9]{2}:[0-9]{2}\s\+[0-9]{4}'

#実はJST⁇の行のチェック

accs_ptn_jst = '[0-9]{2}/\D{3}/[0-9]{4}:[0-9]{2}:[0-9]{2}:[0-9]{2}\s\+0900'

#エラーログの時刻にマッチ

#例:[Tue Jun 07 15:34:25.126709 2670]

error_ptn = '\D{3}\s\D{3}\s[0-9]{2}\s[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{6}\s2[0-9]{3}'

def changeJST(string):

result = ""

jst_time = ""

#もしJST時刻ならスルー

if re.search(accs_ptn_jst, string):

return None

#アクセスログにマッチ

elif re.search(accs_ptn, string):

ff = re.search(accs_ptn, string)

utc = []

#月

ffDec = re.search('/\D{3}', ff.group(0))

utc.append(ffDec.group(0)[1:])

#日

ffDec = re.search('[0-9]{2}', ff.group(0))

utc.append(ffDec.group(0))

#時間

ffDec = re.search(':[0-9]{2}:[0-9]{2}:[0-9]{2}', ff.group(0))

utc.append(ffDec.group(0)[1:])

#時差

ffDec = re.search('\+[0-9]{4}', ff.group(0))

utc.append(ffDec.group(0))

#年

ffDec = re.search('2[0-9]{3}', ff.group(0))

utc.append(ffDec.group(0))

#並べ替え

#形式:Nov 29 06:08:08 +0000 2006

result = "%s %s %s %s %s" % (utc[0], utc[1], utc[2], utc[3], utc[4])

utcDate = datetime.datetime.strptime(result, '%b %d %H:%M:%S +0000 %Y')

jstTimezone = pytz.timezone('Asia/Tokyo')

#Asia/Tokyoへ変換後、元のログフォーマットへ戻す

jst_time = jstTimezone.fromutc(utcDate)

#形式[07/Jun/2018:01:47:12 +0900]

jst_time = jst_time.strftime('%d/%b/%Y:%X %z')

return jst_time

#エラーログにマッチ

elif re.search(error_ptn, string):

ff = re.search(error_ptn, string)

utc = []

#曜日

ffDec = re.search('^\D{3}\s', ff.group(0))

utc.append(ffDec.group(0)[:-1])

#月

ffDec = re.search('\s\D{3}\s', ff.group(0))

utc.append(ffDec.group(0)[1:][:-1])

#日

ffDec = re.search('\s[0-9]{2}\s', ff.group(0))

utc.append(ffDec.group(0)[1:][:-1])

#時間

ffDec = re.search('\s[0-9]{2}:[0-9]{2}:[0-9]{2}', ff.group(0))

utc.append(ffDec.group(0)[1:])

#id

ffDec = re.search('\.[0-9]{6}', ff.group(0))

utc.append(ffDec.group(0))

#年

ffDec = re.search('\s2[0-9]{3}', ff.group(0))

utc.append(ffDec.group(0)[1:])

#エラーログにマッチ

#配列の中身の例:['Thu', 'Jun', '07', '06:35:13', '.378829', '2018']

#並べ替え

#形式:Nov 29 06:08:08 +0000 2006

result = "%s %s %s +0000 %s" % (utc[1], utc[2], utc[3], utc[5])

utcDate = datetime.datetime.strptime(result, '%b %d %H:%M:%S +0000 %Y')

jstTimezone = pytz.timezone('Asia/Tokyo')

#Asia/Tokyoへ変換後、元のログフォーマットへ戻す

jst_error = jstTimezone.fromutc(utcDate)

#形式:[Tue Jun 05 07:44:15.465239 2018]

#Thu Jun 07 15:35:13 2018

jst_time = jst_error.strftime('%a %b %d ')

jst_time += jst_error.strftime('%X')

jst_time += utc[4]

jst_time += jst_error.strftime(' %Y')

return jst_time

else:

return None

#標準入力から読込

for line in sys.stdin:

#オリジナルログの保存ディレクトリの作成

#保存ディレクトリの存在チェック後、存在しなければmkdir

if os.path.isdir("%sfileName" % logDirPath) is not True:

os.makedirs("%sfileName" % logDirPath)

#行末の改行を削除

line = line.rstrip()

#Readでオープン

file = open(line, "r")

newFileName = ""

#念のためファイルの存在チェック後、

#読み込んだファイルを保存ディレクトリへ移動

if os.path.exists(line):

fileName = re.search(fileNamePtn, line)

fName = fileName.group(0)

if re.search(fileName_ptn, line):

fPath = "%sfileName/%s" % (logDirPath, fName)

shutil.move(line, fPath)

#読み込んだファイルを1行ずつ処理

for row in file:

#UTCからJSTへ変換する関数。JSTに変換された日付の文字列が返ってくる

toJst = changeJST(row)

utcToJst = ""

if toJst is not None:

if re.search(accsNamePtn, line):

utcToJst = re.sub(accs_ptn, toJst, row)

elif re.search(errNamePtn, line):

utcToJst = re.sub(error_ptn, toJst, row)

#新規ファイルへの書き込み。無限ループ回避の名前変更

newFileName = line + ".log"

newfile = open(newFileName, "a")

newfile.write(utcToJst)

newfile.close()

file.close()

#元のファイル名へ戻す

if os.path.isfile(newFileName):

os.rename(newFileName, line)

else:

#ファイル全体で修正が無かったときに保存ディレクトリにmvしたファイルを戻す

if re.search(fileName_ptn, line):

fPath = "%sfileName/%s" % (logDirPath, fName)

shutil.copy2(fPath, line)

粗いスクリプトですが、ひとまず期待通りに動くことが確認できましたので、作業するサーバーのhttpdを停止してスクリプトを実行しました。ちなみにAWSのELBがunhealthyを認識して振り分けを開始するまで約1分~2分ほどかかるようです。認識する前にhttpdを止めると502で振り分けもされなくなるので注意が必要です。

処理するディレクトリのバックアップを取って実行。

#処理するファイル数の確認
find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' -c

#スクリプト実行
find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' | python /スクリプトのディレクトリ/changeJst.py > log.txt

#エラーチェックスクリプト実行
find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' | python /ディレクトリ/errCheck.py > errCheck0308.txt

#処理後のファイル数の確認
find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' -c

#差分チェック
diff -s -q -r /ディレクトリ/ /バックアップディレクトリ/ > diff.txt

diff -y /ディレクトリ/access_log.20180304 /バックアップディレクトリ/access_log.20180304.log > diff-fileName_log.txt

#処理するファイル数の確認

find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' -c

#スクリプト実行

find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' | python /スクリプトのディレクトリ/changeJst.py > log.txt

#エラーチェックスクリプト実行

find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' | python /ディレクトリ/errCheck.py > errCheck0308.txt

#処理後のファイル数の確認

find /ディレクトリ/ -type f | grep -E '.*(access|error)_log\.[0-9]{8}$' -c

#差分チェック

diff -s -q -r /ディレクトリ/ /バックアップディレクトリ/ > diff.txt

diff -y /ディレクトリ/access_log.20180304 /バックアップディレクトリ/access_log.20180304.log > diff-fileName_log.txt

なんとか完了です。
サーバー時刻もUTCからJSTへ変更します。
その後、httpdを再起動。
無事に現在時刻が18時に修正されました。
やっと終わっちまえます。

あれ、cronの実行がおかしい

それから様子をみること数日。
dateコマンドやログに出力される時刻はしっかりUTCからJSTに変更がされているけど、cronに設定したタスクの実行時間がおかしい！どうにも9時間遅れて実行されている！と気づきました。
調べてみるとサーバーのタイムゾーンを変更しただけではcronの実行時刻への反映がされないようです。crondを再起動してJSTタイムゾーンの反映が必要でした。。。

crontabの設定ファイルへtimezoneを記述して、crondの再起動。

vi /etc/crontab
------
#下記の行を追記
CRON_TZ=Asia/Tokyo

------

#crondの再起動
service crond restart

vi /etc/crontab

------

#下記の行を追記

CRON_TZ=Asia/Tokyo

------

#crondの再起動

service crond restart

これでcronの実行時間にもJSTが反映されました。

VPSサーバーのリソース不足を回避する方法

福岡拠点の野田です。もうすぐ花見の季節ですね。来週か再来週あたり、お昼休みの合間を縫って花見に行きたいと思っています。

さて、今日は、仮想サーバーのリソース状況について話をしようと思います。
皆さんは、VPS環境で以下のような画面を見たことがありますでしょうか。開発用だったり、低予算の貧弱な環境では、結構こういう場面に遭遇することもあります。

The following exception is caused by a lack of memory or swap, or not having swap configured Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details [ErrorException] proc_open(): fork failed - Cannot allocate memory

上記は、composer を実行した際に発生したエラーです。このエラーがでたあと、httpd をいったん停止してから実行すると普通に実行できたりします。これは、仮想サーバーのリソースが不足するために発生しているエラーになります。こういうときは、都度、エラーが出るたび、httpdを止めて、ということをしなければいけないのでしょうか。

仮想サーバのリソース状況をチェックするには以下のようなコマンドがあります。
cat /proc/user_beancounters

この中のprivvmpagesという値に注目します。これは、プライベート仮想メモリサイズです。リソースを解放するためには、httpd など消費リソースが大きいサービスを再起動するとリソースが解放されます。

以下は、リソース情報をチェックし、閾値を越えてリソースが足りない状態になると httpd サーバーを再起動するスクリプトになります。

/root/bin/restart.sh

#!/bin/bash
test `expr `grep privvmpages /proc/user_beancounters | awk '{ print int(($4-$2)*4/1024) }'` + 0` -lt 800 &amp;&amp; /etc/init.d/httpd restart

1 2	#!/bin/bash test `expr `grep privvmpages /proc/user_beancounters \| awk '{ print int(($4-$2)*4/1024) }'` + 0` -lt 800 && /etc/init.d/httpd restart

シェルを毎分 cron 実行したら、リソースがないときは、httpdを再起動して、適宜、リソースが解放されるという仕組みです。

*/1 * * * * /root/bin/restart.sh

1	/1 * * * /root/bin/restart.sh

ちなみに800 というのはなんとなくの感覚値です(・ω<) 。某VPSサーバーでは、httpd を再起動すると 3000 くらいまで回復します。300 とか切るとセグメンテーションエラーとかメモリ関連のエラーがよく発生します。

これでサーバーのリソース不足でエラーとなるイライラも収まるでしょう。それでは、Have a nice server life!

2023年3月
月	火	水	木	金	土	日
		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