sudos

February 3rd, 2010 by naoya | No Comments | Filed in day

本番サーバ上で、sudo コマンド経由でスーパーユーザ権限で実行することはよくあります。

sudo コマンドはなくてはならないコマンドですが、同時に危険なコマンドでもあります。

今まで、ずっとデフォルトの sudo の設定で使っていたのですが、改めて設定を見直してみました。

sudo の公式ページをみてみると、頻繁にバージョンアップされているのがよく分かります。/etc/sudoers の設定方法も詳しいドキュメントがあっていい感じです。

次の2点ほど設定を見直しました。

  • デフォルトのパスワードのキャッシュ時間を 0 にする
  • パスワードプロンプトにホスト名を表示する

まず、最初の設定はデフォルトだと 5 分間、パスワードがキャッシュされます。そうすると、連続で sudo コマンドを実行するとき、パスワードを聞かれないためオペミスを起こしてしまう可能性が高まります。そこで、キャッシュ時間を 0 にすることにより、必ず毎回パスワードを聞くように設定します。この設定は、visudo コマンドを使って、次の行を追加します。

Defaults timestamp_timeout = 0

次にパスワードを聞かれるときのプロンプトにホスト名を表示して、念のためどのホストで sudo を実行しようとしているのか表示します。次の行を追加します。

Defaults passprompt = “%u@%h Password: “

この設定をすると、例えば hoge というユーザ名で、s1 というホスト名の場合、次のようなパスワードプロンプトになります。

hoge@s1 Password:

デフォルトのパスワードプロンプトに比べると、かなり分かりやすい表示になりました。

最新版の sudo バージョン 1.7.1 以降からは、次のような構文で別の設定ファイルも読み込めるようになっています。

これを使えば、ホストごとに異なった設定も管理しやすくなります。ただし、CentOS の場合、バージョン 1.6.8 なので対応していません。すこしはまってしまいました。。。

#includedir /etc/sudoers.d/hoge

最新版の sudo に入れ替えようと思いましたが、今のところそれほど困っていないので最新版は使っていません。

普段何気なく使っている sudo。もちろん、なるべく本番サーバ上では使わないのが賢明ですが、メンテナンスのときなど使う機会があるので、なるべくオペミスのリスクを減らしたいものです。

さらに、僕は sudo をコマンド補完履歴に追加しないようにしています。

# 2/5 追記

ちなみに、sudo のパスワードキャッシュをクリアするときは sudo -k あるいは -K オプションで行います。

Tags:

サーバの消費電力 -NEC サーバ編-

January 27th, 2010 by naoya | No Comments | Filed in day

いつも、DELL サーバばかりのエントリばかりだったので、今回は久しぶりに違う内容をエントリします。

NEC サーバの 1U サーバの NEC Express 5800 シリーズの 2 種類の消費電力を測定する機会があったので、計測結果を紹介します。

計測方法は、前回の DELL サーバのときと同じクランプメーターで測定しました。

NEC Express 5800/R120a-1

  • CPU: Intel Xeon X5570 2.93GHz x 2
  • Memory: 32GB
  • HDD: Seagate Savvio ST973452SSS SAS 60GB x 6 (ハードウェア RAID 0)
  • Power: 冗長電源付き(2系統に電源が入っている場合、方側の電源を抜くともう片側に2倍の電力がかかる)
  • 消費電力 idle: 0.86A
  • 消費電力 max: 1.74A

NEC Express 5800/120Rh-1

  • CPU: Intel Xeon E5420 x 1
  • Memory: 8GB
  • HDD: Western Digital SATA 160GB x 1
  • Power: 冗長電源なし
  • 消費電力 idle: 1.76A
  • 消費電力 max: 2.10A

Xeon E5420 は、Intel のホームページを見ると 80w ですが、かなり消費電力が高いのが、特徴的でした。

サーバ本体の価格、消費電力、どちらをとるのか、サーバの用途によって決めていくのが重要だと思う今日この頃です。

Tags:

DELL スイッチでサービスタグを確認する方法

January 26th, 2010 by naoya | No Comments | Filed in day

前回に引き続き、今回は DELL スイッチでサービスタグを確認する方法です。DELL スイッチのサービスタグは、背面にあるため一度ラックにマウントしてしまうと、サービスタグを確認するのがかなりめんどうです。

DELL スイッチには、いくつか種類がありますが、PowerConnect 54XX より上位のモデルは、telnet 接続してスイッチの設定をする機能があるので、telnet 接続することでサービスタグを確認することができます。

例えば、switch1.example.com というスイッチがあった場合には、次のように設定します。

$ telnet switch1.example.com

User name: admin

Passowrd: スイッチの管理パスワード

switch1.example.com# show system

System Description:                                        PowerConnect 5448
System Up Time (days,hour:min:sec):       237,08:32:02
System Contact:
System Name:                                                 switch1.example.com
System Location:
System MAC Address:                                  XX:XX:XX:XX:XX:XX
System Object ID:                                         1.3.6.1.4.1.674.10895.1234
Type:                                                               Ethernet Switch
Asset tag:
Service tag:                                                    1234567

Main Power Supply Status:    OK
Fan 1 Status:                             OK
Fan 2 Status:                             OK
Fan 3 Status:                             OK

Unit            Temperature (Celsius)            Status
———————— ———————— ————————
1                        52                       OK

上の出力にある Service  tag: という欄で、DELL スイッチのサービスタグを確認することができます。あわせて、スイッチの電源状態、ファンの状態、などもチェックすることができるので、とても便利です。時間があいたときにでも、スイッチの状態を確認する Nagios プラグインでも書いてみようかと思います。

なお、もっとも安価な PowerConnect 28xx シリーズには、その機能がないので注意してください。ただし、ウェブの管理画面があるので、そこから確認することができます。

ちなみに、DELL スイッチにはエクスプレスコードはありません。サービスタグのみで、問い合わせすることが可能です。

Tags:

DELL サーバー Tips

January 23rd, 2010 by naoya | No Comments | Filed in day

今日は、DELL サーバーの Tips を一つ紹介したいと思います。DELL サーバには、サポートに問い合わせるときのために、筐体ごとにサービスタグエクスプレスコードという ID が割り当てられています。

この ID は、1u サーバだと筐体の正面にシールで張り付けされています。R410 などのちょっとよい 1U サーバの場合、正面の LCD にもスクロールされて標準されています。

RX1Xの場合: www.dell-faq.com -Q&A検索- FAQ詳細

何らかの問い合わせがあるとき、このサービスタグとエクスプレスコードを確認する必要がありますが、いちいち筐体の前に行って確認するのはめんどうです。

DELL から、このサービスタグとエクスプレスコードを確認するための RHEL 用のコマンドが配布されているので、これを利用すると便利です。

まず、DELL 非公式の yum リポジトリを追加します。

$ wget -q -O – http://linux.dell.com/repo/community/bootstrap.cgi | sudo bash

bootstrap.cgi は、ソースコードをみて分かるとおり、CentOS もしっかりサポートされています。上のコマンドを実行すると、DELL 非公式の yum リポジトリが追加されますので、あとはプログラムをインストールします。

$ sudo yum install libsmbios-bin

そうすると、/usr/sbin/getSystemId というコマンドを python で書かれたコマンドラインツールがインストールされます。次のように、このコマンドを使うと簡単にサービスタグとエクスプレスコードを確認することができます。

$ sudo /usr/sbin/getSystemId

Libsmbios version:        2.2.17
Product Name:               PowerEdge R300
Vendor:                            Dell Inc.
BIOS Version:                 1.2.0
System ID:                       0×0123
Service Tag:                     1234567
Express Service Code:   1234567890
Asset Tag:
Property Ownership Tag:

–help すると詳しいコマンドの使い方が分かりますが、例えばサービスタグだけ取得したいときは、次のように実行します。

$ sudo /usr/sbin/getSystemId –service-tag

これを応用すれば、サービスタグとエクスプレスコード用のカスタム facter も書けますし、資産管理のときにもまとめて集められるので、とても便利です。

僕の場合は、管理している本番サーバ上で getSystemId を使ってすべてのサービスタグとエクスプレスコードを集めて、社内 wiki に一覧としてまとめてあります。

Tags:

それでも私が CentOS を使いつづける理由また、Why I still use CentOS? 的な。

January 21st, 2010 by naoya | No Comments | Filed in day

元ネタ: 漢(オトコ)のコンピュータ道: それでも私が MySQL を使いつづける理由または、Why I still use MySQL? 的な。

同じくノリが楽しそうだったので CentOS で便乗してみました。

Fast Enough

正直なところ、特に速いと思ったことはあまりない。

Stable

商用版をベースにしているため、安定している。ちゃんと対応しているプログラムが多い。

バージョンアップが枯れ過ぎているので、かなり安定している。

Easy to install

Live CD ですぐに試せたり、インストール CD を使えば、すぐに分かりやすいグラフィカルなインストーラでインストールすることができる。インストール CD をダウンロードするのがめんどうだという人向けにネットワークインストール用のインストールイメージも用意されている。

Gnome/KDE や仮想環境 (KVM) やクラスタリング環境がすぐにセットアップできるのが便利。

さらにインストール後に、root ユーザのホームディレクトリに生成される kickstart ファイルを使えば、同じ設定で何度もインストールすることが可能なところも魅力である。

CentOS have enough users.

RHEL のユーザを含めば、恐らく Linux ディストリビューションのユーザ規模では最大規模になると思う。そのため、日本語の書籍やインターネット上の情報が豊富である。

まとめ

以上に述べた点に比べると、プロジェクトが崩壊の危機にあったとか、Linux Kernel のバージョンが 2.6.18 云々とかは些事にすぎない。

改訂第二版 CentOSサーバ構築バイブル
平 初 伊藤 幸夫 上鍵 忠志 中澤 直也 面 和毅 館林 綾ノ介 高安 洋輝 宇野 素史 坂井 恵
毎日コミュニケーションズ
売り上げランキング: 55121

Tags:

美しいデータセンター

January 16th, 2010 by naoya | No Comments | Filed in day

ふと海外のデータセンターに関する情報を調査していたとき、Beautiful Web Hosting Datacenter Images | UnixNewbie.org という記事に、各データセンターの美しい様子が紹介されていました。

せっかくなので、その写真の一部を紹介します。大きな写真は、元記事から見てください。

まずは、日立のグリーンデータセンター。これは、実物ではなく構想上の写真のみです。

次に Facebook のデータセンター。これは貴重な写真だと思います。ネットワークのケーブリングまわりも要チェックです。サーバ一台あたりに、2本から3本くらいのケーブルが接続されているのが分かりますね。おそらく冗長化目的というより、ネットワークを分離しているような気がします。

そして、昨年大きな話題になった Google。Google サーバのケーブルは、各サーバに一本ずつです。シンプルな構成で、かなり割り切った構想のようです。

そして、Microsoft のデータセンター。

Planet  データセンター。DELL サーバだらけです。よくこれで1ラックに詰め込むができますね。ラックの上部にスイッチを配置しているのが新鮮です。

美しいネットワークのケーブリング。

次のケーブリングは、僕の方式とかなり近いです。

次のようなスパゲッティな状態も、別の意味で美しいです。

一度、Facebook か Google か Amazon の巨大データセンターを見てみたいものですね。

Tags:

Hadoop で syslog 経由でログを出力する方法

January 13th, 2010 by naoya | No Comments | Filed in day

Hadoop を使いはじめたのですが、Hadoop で出力されるログを syslog 経由で出力するように設定してみました。最初は、log4j.properties だけ書き換えればよいかと思ったのですが、これだけでは syslog 経由でログを出力できませんでした。

Hadoop は、CDH のバージョン 0.18.3 を使っています。

まず、/usr/lib/hadoop/bin/hadoop-daemon.sh で、log4j の logger 環境変数を使えるように次のように変更します。次のパッチでは、念のためローカルのログファイル名も変更できるようにしてあります。

/usr/lib/hadoop/bin/hadoop-daemon.sh
28a29,30> #   HADOOP_LOGFILE  The log file name. Default is hadoop-$HADOOP_IDENT_STRING-$command-$HOSTNAME.log
> #   HADOOP_ROOT_LOGGER   The root appender. Default is INFO,console
84a87,94
> # log configuration
> if [ "$HADOOP_LOGFILE" = "" ]; then
>   export HADOOP_LOGFILE=hadoop-$HADOOP_IDENT_STRING-$command-$HOSTNAME.log
> fi
> if [ "$HADOOP_ROOT_LOGGER" = "" ]; then
>   export HADOOP_ROOT_LOGGER=”INFO,DRFA”
> fi
>
86,87d95< export HADOOP_LOGFILE=hadoop-$HADOOP_IDENT_STRING-$command-$HOSTNAME.log
< export HADOOP_ROOT_LOGGER=”INFO,DRFA”

次に、/etc/hadoop/conf/hadooop-env.sh に、次のように追加します。

export HADOOP_ROOT_LOGGER=”INFO,SYSLOG,DRFA”

最後に、/etc/hadoop/conf/log4j.properties に syslog で出力するための log4j の appender を追加します。

#
# syslog
#
log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
log4j.appender.SYSLOG.facility=local0
log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
log4j.appender.SYSLOG.layout.ConversionPattern=%p %c{2}: %m%n
log4j.appender.SYSLOG.SyslogHost=127.0.0.1
log4j.appender.SYSLOG.threshold=INFO
log4j.appender.SYSLOG.Header=true
log4j.appender.SYSLOG.FacilityPrinting=true

あとは、Hadoop を再起動すれば、127.0.0.1 のサーバに 514 番ポート、UDP、local0 ファシリティ、にて Hadoop のログが転送されます。どうやら、TCP にすることができないみたいです。

hadoop-daemon.sh の方は、本家でバージョン 0.21 で対応予定のようです。

参考資料

Tags:

syslog-ng と rsyslog

January 8th, 2010 by naoya | No Comments | Filed in day

そろそろ本格的に、CentOS な本番サーバを syslog-ng あるいは rsyslog に切替えようと、実際に試してみました。切替えたい目的は、必要なログは集中管理したいためです。今回は、本番環境でも使う Apache のアクセスログを他のサーバに転送するための設定方法だけ紹介します。

まずは、syslog-ng。

syslog-ng の本家サイトをみると、次のような3種類のバージョンがあります。

  • オープンソース版: フリー、syslog-ng のオープンソースブランチ
  • プレミアム版: いくつかの追加機能をオリジナルのオープンソース版 syslog-ng からフォークした商用版
  • ストアボックス版: ログのライフサイクル管理の中央ログサーバアプライアンス

次に CentOS では、バージョン 2.1.4 が EPEL のリポジトリから提供されています。本家サイトでは、次のバージョンが stable として提供されています。

  • 3.0.5 – 3.0.1
  • 2.1.4 – 2.1.3
  • 2.0.10

EPEL で提供されているのは、2.1 系の最新版ということになります。最新版のバージョン 3 系の changelog は、ここで確認できます。おもな変更は、次の内容になります。

  • IETF によって策定された新しい syslog プロトコルの標準に対応した、具体的な仕様はここここを参照してください
  • Log ステートメントに他の複雑なログのパスを組み込むことができるようになった
  • 元ファイルの文字コードを設定することが可能になった(内部的には、syslog-ng はすべてのメッセージを UTF-8 として記憶している)
  • syslog-ng のアプリケーションは、すべてのログメッセージに対してユニークなメッセージ識別子を付与できるようになった
  • syslog-ng のアプリケーションは、テンプレートや正規表現を使って構造化されたメッセージを読み込んだり、処理できたり、書き直すことができるようになった(例えば、Apache のウェブサーバログ)。フィールドサイズを変更することとデリミッターで区切られているフィールドの両方のメッセージをサポートした

それほど大きな変更点はないようなので、EPEL で提供されているものを十分だと思われます。EPEL が利用できるなら、インストールは次のコマンドでできます。

$ sudo yum install syslog-ng

インストールすると、制御スクリプトが /etc/syslog-ng、設定ファイルが /etc/syslog-ng/syslog-ng.conf にインストールされます。

実際に使用する前に、syslog-ng のおもな特徴をまとめておきます。

  • 既存の syslog の設定ファイルと互換性がない(デフォルトでインストールされている設定ファイルがデフォルトの syslog の設定と同じになっています)
  • facility などで細かく出力するログの内容を設定することができる
  • 出力するログファイル名に、日付などを設定することができる(これによりログローテート入らずになります)
  • UDP/TCP によって、任意のサーバへログ転送することができる(デフォルトのポートは、514)
  • facility、priority、ホスト名、アプリケーション名、などで自分のプログラムを起動することができる

syslog-ng と rsyslog は、従来の syslog を置き換えるものなので、事前に syslog を必ず止めて起動しないようにしておきます。(さようなら syslog、今までありがとう syslog…)

$ sudo /etc/init.d/syslog stop

$ sudo chkconfig syslog off

今回は、Apache のアクセスログを syslog-ng と rsyslog でシスログ転送する方法をそれぞれ紹介します。

Apache のアクセスログは、パイプで logger コマンドを指定すると syslog へ出力することができます。

CustomLog “|/usr/bin/logger -i -p local4.info -t httpd” combined

syslog-ng の設定は、次の内容を /etc/syslog-ng/syslog-ng.conf に追加します。

filter f_httpd {
facility(local4) and level(info);
};

destination d_httpd {
file(“/var/log/syslog_httpd_access_log”);
udp(“192.168.1.2″);
};

log { source(s_sys); filter(f_httpd); destination(d_httpd); };

上のように設定しておくと、/var/log/syslog_httpd_access_log にアクセスログが出力されて、かつ 192.168.1.2 のサーバにログを UDP で転送するという設定になります。

192.168.1.2 の syslog-ng の設定は、s_sys source のコメントをはずします。なお、UDP/TCP の 514 ポートが iptables でブロックされていないか確認しておきましょう。tcp にしたい場合には、udp を tcp に置き換えます。

udp(ip(0.0.0.0) port(514));

syslog-ng を起動する前に、設定ファイルに記述ミスがないかどうか調べてみます。

$ sudo /etc/init.d/syslog-ng checkconfig

Checking Configuration:                                    [  OK  ]

問題がなければ起動してみます。

$ sudo /etc/init.d/syslog-ng start

Starting syslog-ng:                                        [  OK  ]

これで、httpd へのアクセスログがローカルのディスクに出力されて、かつ 192.168.1.1 のサーバにも同じ内容が転送されてアクセスログとして出力されます。

syslog-ng の設定項目は、膨大なので公式ドキュメント(PDF 形式)を参考にしたほうがよいと思います。

次に rsyslog。

rsyslog は、CentOS の base リポジトリで、バージョン 2.0.6 が提供されています。rsyslog にも、いくつかのバージョンが stable として提供されています。

四系統もバージョンがあり、かなり複雑な印象をうけます。v2 と v3 では、互換性がないようで専用の互換モードが用意されています。それぞれのバージョンでも互換モードが用意されています。v2 は、すでにサポートされていないので、v3 stable 以降を使うといいと思います。

ちなみに、Fedora では Fedora 8 から、syslog のかわりに rsyslog を採用しています。最新版の Fedora 12 では、rsyslog のバージョンは 4.4.1 でした。

なので、v4 stable のバージョン 4.4.2 を使うのがよさそうです。このバージョンは、RPM では提供されていないので、Fedora プロジェクトのものを使って RPM を作成するといいと思います。Fedora プロジェクトのもので RPM を作成すると、sysklogd パッケージと /etc/logrotate.d/syslog がコンフリクトしてしまいますが、従来の /etc/logrotate.d/syslog の内容と同じもので rsyslog の RPM を作成すればコンフリクトを解消することができます。設定ファイル内のスペースとタグも区別するので、まったく同じ内容になるように作成してください(僕はここですこしはまりました…)。

rsyslog をインストールすると、制御スクリプトが /etc/init.d/rsyslog、設定ファイルが /etc/rsyslog.conf、にインストールされます。rsyslog.conf をみて分かるとおり、従来の syslog の設定ファイルとほぼ同じ内容になっています。

rsyslog のおもな特徴は、次のとおりです。これらの機能は、syslog-ng では提供されていない機能だと思われます。特に圧縮転送はうれしい機能の一つです。マクロは、syslog-ng と同じようなものが提供されています。その他の詳しい機能は、本家サイトで確認してください。

  • MySQLやPostgreSQLをモジュールなどで拡張することなく、ネイティブでサポート
  • libdbiを使用すれば、Firebird/Interbase/MS SQL/SQLLite/Oracleなどに対応可能
  • 圧縮転送が可能
  • stunnelを使ったシスログのセキュアな転送が可能
  • シスログのディスク書き込みで、I/Oの処理が間に合わない場合など、スプールを使用することができる。特にバックエンドにデータベースを使用している場合に有効に機能する

Apache のアクセスログを出力している側の rsyslog の設定は、次の内容を追加します。

local4.info @@192.168.1.2

たったこれだけです。@@ というのは、TCP でログを転送するという意味になります。UDP で転送したい場合は、@ と指定します。

syslog-ng と rsyslog、どちらも試してみましたが、どちらもほぼ同じ機能が提供されています。設定ファイルの書き方が、まったく違うので、どちらかを常用するべきか決めたほうがいいと思います。

僕の場合、CentOS であること、Fedora が rsyslog を標準採用したということで、RedHat もそろそろ標準採用しそうか感じがあるので、rsyslog を本番環境へ本格的に投入してみることしました。

rsyslog を本番環境へ投入するにあたりかなりはまったので、この内容は別にエントリする予定です。

Tags:

年始めのご挨拶

January 3rd, 2010 by naoya | No Comments | Filed in day

いよいよ、2010 年が始まりました。今年も、特にインフラまわりのアウトプットを、このブログで行いたいと思います。

個人的な 2010 年のおおよその目標は元旦に決めましたが、今年はいろいろと自分の環境を変えていく年になりそうです。

ということで、今年 2010 年も Carpe Diem をよろしくお願い致します。

Naoya Nakazawa

Tags:

The Art of モバゲー Capacity Planning

December 31st, 2009 by naoya | No Comments | Filed in day

さて、2009 年も残すところ、あとわずかとなりましたが、今日はモバゲー版のキャパシティプランニングを考えてみましょう。モバゲー版は、まだ実際にはサードパーティ製のアプリが公開されていない状況だとは思いますが、開発サイトが公開されています。モバゲー版も、mixi モバイルアプリ版と同様に、パートナー企業のみが開発できるようになっています。

まず、モバゲーの規模を知るために、 月次推移のご報告(平成21年10月度)を見てみましょう。この資料から、2009 年 10 月時点での PV は、次のようになっています。

  • 会員数: 1527 万人
  • 月間 PV: 約 238 億 PV
  • 単純平均して、日間にすると約 8 億 pV、秒間にすると約 9,259 PVになります

次に、モバゲーの成長速度を計るため、月次推移のご報告(平成21年8月度)を見てみましょう。この資料から、2009 年 8 月時点での PV は、次のようになっています。

  • 会員数: 1220 万人
  • 月間 PV: 約 198 億 PV
  • 単純平均して、日間にすると約 6.6 億 PV、秒間にすると約 7,638 PVになります

そうすると、2009 年 10 月から三ヶ月前経過した 2010 年 1 月には、最低でも次の数字になっていると推測されます。

  • 会員数: 1800 万人
  • 月間 PV: 約 280 億 PV
  • 単純平均して、日間にすると約 9.3億 PV、秒間にすると約 10,802 pv になります

さすがは、モバゲーというだけあって、mixi のモバイル版よりはかなり規模が大きいです。

モバゲーの場合も夜の時間帯に約 3 倍のリクエストがあるとなると、モバゲー本体で秒間あたり約 3 万 PV になります。

モバゲーアプリはまだ公開されていないので、モバゲーの会員数のうちいったいどのくらいのユーザがモバゲーアプリが使うかは分かりませんが、すべての会員がアプリを使うことは当り前ですがありません。

おそらく、約 2 割のユーザが使って、アクセスが集中する時間帯で約 3 倍になると仮定すると、おおよそ次のくらいの規模になりそうです。

  • 会員数: 約 350 万人
  • 月間 PV: 約 60 億 PV
  • 日間 PV: 約 2 億 PV
  • 秒間最大 PV: 約 6,000 PV

モバゲーも mixi 版と同様にかなりの規模になることが分かりました。

いよいよ今年から、日本でも OpenSocial 対応を表明していたサイトが続々と実際にそれぞれのプラットフォームを公開してきました。OpenSocial 対応のアプリを開発しているのは、前でもエントリしたとおりいわゆるベンチャー企業が多いので、これだけの大きなトラフィックをいかに低コストでかつ確実にさばけるかがアプリの成功の鍵を握っていると思います。

個人的には、このような大きなトラフィックをさばくということに、とても大きな関心と興味があるので、来年はさらにもうすこし踏み込んでいかにして低コストでかつ確実にさばくか考えていきたいと思います。

それでは、よい年をおむかえください!