Cybozu Inside Out | サイボウズエンジニアのブログ

 

@lestrrat 氏に Kubernetes を教えてもらいました

@ymmt2005 こと山本です。SRE とかやってます。

サイボウズでは「Neco」という、クラウド基盤のアーキテクチャを刷新するプロジェクトを進めているのですが、今回は @lestrrat こと牧大輔さんをお招きして Kubernetes の導入を検討しはじめた話です。

当日の牧さんの資料は以下で公開されています。

現状のシステム

サイボウズのクラウド基盤は 1,000 台規模の物理サーバーと数千台の仮想マシンの上で動作する数々のサービス群で構成されています。どのサービスをどのサーバー・VM で動作させるかは現状人手による暖かみのある管理方式で、規模の増大に伴い工数も増えています。

多数の物理サーバーを保有しているので遊休リソースも相当あります。画像変換処理などで遊休リソースを有効活用する Kodama という仕組みも自製しているのですが、Kodama に遊休リソースを割り当てるのは人手になっており、自動化しきれていません。

アプリケーションのデプロイに関しても、Docker 等のコンテナ技術を採用できておらずバージョンアップ作業などで一々人手による設計・実装作業が必要な状況です。

Neco でやりたいこと

次期アーキテクチャで目指す理想はこんなところです:

  • CPU やメモリといったリソースの空き状況を見て自動的に適切なサーバーを選択
  • サーバー故障時や退役時の自動的なサービス再配置
  • 配置されたサービスの発見方法(サービスディスカバリ)を提供
  • アプリケーションはコンテナとしてデプロイ

Kubernetes とは

Dockerrkt の登場で近年 Linux のアプリケーションのデプロイは急速にコンテナ化が進んでいます。

ただ、素のコンテナエンジンではデータセンターで運用するうえで必須となる冗長化やサービスディスカバリの機能がないため、開発環境はともかく、大規模な運用に必要なパーツに欠けている状況でした。と、いうのは一昔前の話です。

現在はコンテナを大規模な分散環境で自動的に管理するミドルウェアの開発が活発に行われています。代表的なものは以下です。

Kubernetes は元々は Google が開発していたものをオープンソース化したもので、その経緯から特に GCP では容易に利用できるようになっています。

勉強会の内容

社内で声をかけたところ、牧さん直々の勉強会ということで 10 名以上参加して実施しました。 勉強会の参加者は、一通り以下のチュートリアルをこなして参加しました。

牧さんの資料をもとに、builderscon のサイトを実際に k8s でどのように管理しているかや、以下のような便利ツールを教えてもらいました。

記念写真 f:id:cybozuinsideout:20170316134134j:plain

今後の予定

もくろみ通り、k8s 熱が社内で盛り上がっている状況です。当社のようなオンプレミス環境での構築はそこそこ大変そうですが、まず開発用データセンターに構築してノウハウを貯めていきます。

知見がたまりましたらまたブログで公開していきますので、応援よろしくお願いします。

お忙しい中勉強会を引き受けてくださった牧さん、ありがとうございました!

 

「障害に捨てるところなし」というお話をしました

どうも!アプリケーション基盤チームの@yokotasoです。 3月11日にBattle Conference U30 というイベントでお話をさせていただきました。 準備がてら作成したディスクリプションを公開します。

キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。

では、どうぞ!

障害にすてるところなし

f:id:cybozuinsideout:20170310102053p:plain:w300

サイボウズ株式会社の横田です。

「障害に捨てるところなし」というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。

運用障害の話

f:id:cybozuinsideout:20170310102337p:plain:w300 f:id:cybozuinsideout:20170310102652p:plain:w300

まずはじめに、今回のお話をするにあたりまして

運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。 より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。

これからも、弊社製品をよろしくお願いいたします。

クラウドの規模と稼働率

f:id:cybozuinsideout:20170310104031p:plain:w300

障害の話をする前に、サイボウズのクラウドの規模感についてお話させてください。

ご契約いただいている会社様は18000社、ビジネス規模では、年間の売上が40億程度の規模になってきています。 稼働率は99.9 % をだいたいクリアするくらいです。

さて本題

f:id:cybozuinsideout:20170310104725p:plain:w300 f:id:cybozuinsideout:20170310104728p:plain:w300

障害というとネガティブなイメージを持たれがちなんですが、

f:id:cybozuinsideout:20170310104731p:plain:w300

ちょっとまってそんなことないよと。

f:id:cybozuinsideout:20170310104734p:plain:w300

チョットイイね!くらいまで持っていこうよという話をしたいなと思います。イイねマーク、気持ち小さくなっております。

f:id:cybozuinsideout:20170310104737p:plain:w300

4つのネタで、失敗から徹底的に学ぶ障害学習の話をしていきたいと思います。

基礎知識を身につける

さて、1ネタ目。基礎知識を身につける。基礎的な素養を磨く話です。

f:id:cybozuinsideout:20170310105626p:plain:w300 f:id:cybozuinsideout:20170310105629p:plain:w300

障害からコンピュータの基礎を学ぶ

f:id:cybozuinsideout:20170310105835p:plain:w300

コンピュータの稼働状況を表す基本的な指標としてCPU、メモリ、ディスク、OSキャッシュなどがあります。

障害調査はボトルネック探しからはじます。

大規模サービス技術入門 という素晴らしい本があります。本を参考にしながら、何度も障害調査をしていくと、基礎的知識が身につきます。私もお世話になりました。

障害のたびにメトリクス監視ツールなどを眺めることになると思いますが、こういう経験をしていくと基礎的な素養と経験が身につきます。

障害がコンピュータの基礎を教えてくれた

f:id:cybozuinsideout:20170310105838p:plain:w300

こうして得た知識と経験は今の私にとっては素晴らしい財産です。障害調査、設計などにとても役に立っています。 問題の原因がわからないとき、落ち着いて基本的な指標に立ち返って解決に向かったこともあります。

f:id:cybozuinsideout:20170310111001p:plain:w300

「コンピューターの大切なことは、障害が教えてくれた」といってもいいと思います

知識を深掘りする

2つめのネタは、知識を深掘りする話です。

f:id:cybozuinsideout:20170310111712p:plain:w300

f:id:cybozuinsideout:20170310111715p:plain:w300

障害を通して、動作原理を深く理解しましょう。

f:id:cybozuinsideout:20170310111717p:plain:w300

MySQLIndexが使えないことが原因で障害になったことがあります。

f:id:cybozuinsideout:20170310111721p:plain:w300

原因としましては、重複を取り除くために安易につけたGROUP BYが原因でした。 MySQLJOINのときにIndexを利用するんですが、そのIndex とは違う列で GROUP BY を行うのでusing filesort になってしまう。 味わい深いですね。

f:id:cybozuinsideout:20170310111723p:plain:w300

この問題、MySQLIndex に関する動作原理からすると非常にあたり前な現象です。 この障害を通して、MySQLIndex を使った動作原理が実は理解できていなかったことがわかりました。 障害調査のたびに、ハイパフォーマンスMySQL を何度も読み返してやっと理解できたなと。

f:id:cybozuinsideout:20170310111726p:plain:w300

最初は理解できないことでも、直面した問題を読み解くことで、プログラムに関する深い理解が得られるのです。 障害は最高の良問だと私は思っています。

チームで強くなる

3つめは、チームの話です。失敗がすることは誰でもあります。であれば、失敗を受け入れるほうに注力するのも筋は悪くないはずです。

f:id:cybozuinsideout:20170310114542p:plain:w300 f:id:cybozuinsideout:20170310114544p:plain:w300

失敗の名は

f:id:cybozuinsideout:20170310115045p:plain:w300 f:id:cybozuinsideout:20170310115048p:plain:w300

弊社もご多分に漏れず、おおきな失敗をしております。 S2DaoからHibernateへの移行に失敗しました。パフォーマンス劣化、障害を起こしました。ご迷惑をおかけしました。 言い訳になりますが、S2Dao、いいフレームワークなんです。EOLなのが残念です。

失敗を受け入れる文化

f:id:cybozuinsideout:20170310115315p:plain:w300

じゃあ、どうやって失敗をうけいれるのかという話です。

f:id:cybozuinsideout:20170310115401p:plain:w300

私がおすすめするのはPostmortemを書くことです。Postmortemは振り返り文章のことで、失敗を整理、分析、共有するのに役立ちます。超有名企業の大規模障害のPostmortemをWebで読めるようになっていたりします。Webに公開する必要はないですが、チームでこういった文章を共有して話せる文化があるといいですよね。

失敗を共有する文化

f:id:cybozuinsideout:20170310120045p:plain:w300

失敗を共有することで、同じ失敗を繰り返さないように組織の問題として捉え直すことが出来ます。

ありがちな話ですが、失敗を共有するのは恥じらいや申し訳無さから難しいことが多いです。 話してくれた人には圧倒的感謝を。謙虚・尊敬・信頼(HRT) の精神で傾聴をぜひお願いします。

f:id:cybozuinsideout:20170310120444p:plain:w300

手前味噌になりますが、この移行失敗の顛末はブログに公開していますので、興味があればぜひ読んでみてください。 参考: 我々はいかにして技術選択を間違えたのか 2016

転んでもただでは起き上がらない

f:id:cybozuinsideout:20170310120635p:plain:w300

失敗を受け入れる話をしてきましたが、失敗は成功の道半ばでしかないという開き直りも大事です。

f:id:cybozuinsideout:20170310120815p:plain:w300

失敗したときの悔しいエネルギーがないと改善できないことってあると思うんです。 弊社も今回の失敗から立ち直るべく JdbcTemplate を使ってS2DAOに近いORMapperを再設計しました。 近いうちにOSSとして公開したいと思っているので、お楽しみに

f:id:cybozuinsideout:20170310121326p:plain:w300

失敗の共有は恥だが役に立つという話でした

よこしまな生き方について

4つめ。エモい話ですけど、よこしまな生き方についてです。

f:id:cybozuinsideout:20170310122807p:plain:w300

Javaの謎のパフォーマンス現象との戦い

f:id:cybozuinsideout:20170310122916p:plain:w300

Javaの謎のパフォーマンス劣化現象に苦しめられていた時期がありました。

f:id:cybozuinsideout:20170310122919p:plain:w300

無事解決しまして、原因はJIT Compilerでした。 JIT Compilerが停止したままになるのと、最適化されたコードを捨てる機能があり、これが悪さをしていました。

解決の糸口

f:id:cybozuinsideout:20170310122922p:plain:w300 f:id:cybozuinsideout:20170310123231p:plain:w300

どうやって解決したのか?という話なんですが、JVMはGCに使われるスレッドはCPUのコア数から決まります。 そして、GCスレッドは、CPUを100%専有する仕様になっています。このあたりの話はJavaパフォーマンスにあります。

これを前提にすると、GCが常に発生していたとしても、運用環境のCPUはまだ余裕がありました。そこで初めて、GCを原因から排除しました。 あとは、CPUを消費するケースをMLで読み漁りまして、発見したのが今回の現象でした。

ブログに公開

f:id:cybozuinsideout:20170310123244p:plain:w300

調査に苦労したので、少しでも元を取ろうということでブログ記事に公開しました。

f:id:cybozuinsideout:20170310123246p:plain:w300 f:id:cybozuinsideout:20170310123249p:plain:w300

公開時に読んでいただいた方もいるかもしれません。ご愛読ありがとうございます。 記事は大好評でした。OSSにお世話になっているので、情報公開で貢献したい気持ちもありました。

結果的には、3日間ぐらいドヤ顔してましたが。

参考: Javaの謎のパフォーマンス劣化との戦い

ずぶとく生きるように

f:id:cybozuinsideout:20170310123253p:plain:w300

このときの経験から、調査のモチベーションがガラリとかわりました。 現金なもので、面白いことがあるかもしれないと調査していると不思議と楽しいです。疲れますけど。

JIT Compilerの問題が長期間、原因不明だったので開き直れるようになりました。 いざとなったら逃げてもいいと実感できたことはとても大きな学びでした。

ずぶとくネタを使いまわして、今日も喋りに来ているわけです。

f:id:cybozuinsideout:20170310123256p:plain:w300

常にネタを探しているお笑い芸人みたいですけど、ちょっとよこしまな気持ちを持っていたほうが人は楽しく生きられるのかもしれません。

おわりに

最後になりますが、今日の話を聞いて障害調査に興味を持っていただける人が増えたらうれしいです。

f:id:cybozuinsideout:20170310123300p:plain:w300

障害学習、はかどりまっか?

f:id:cybozuinsideout:20170310123303p:plain:w300

障害にすてるところなしという話でした。ありがとうございました

引用

プレゼンテーションで引用させていただきました。日々、業務でお世話になっております

 

Cybozu Meetup #1 フロントエンド を開催しました!

こんにちは。Garoonのプログラマーをしている杉山です。2月27日にサイボウズで初めてとなるCybozu Meetupを東京・大阪の2会場で同時開催しました。今回はこの会の様子を紹介したいと思います。

Cybozu Meetup って?

Cybozu Meetup Logo サイボウズの技術・製品・文化など毎回異なるテーマをネタにお寿司とドリンクを楽しむイベントです。エンジニアのみなさんとサイボウズの社員がカジュアルに交流・情報交換できることを目的にしています。

初めての開催となった今回はフロントエンドをネタに、東京オフィス・大阪オフィスの2会場で同時開催しました。

2会場合わせて150名近くの応募があった中、最終的に約40名の方に参加いただきました。参加いただいた皆様、改めてありがとうございました!

トークセッション

交流会前のトークッセッションは開発本部長の佐藤鉄平(@teppeis)の『サイボウズのフロントエンド開発の現在とこれからの挑戦』でした。

Meetup の様子

当日の様子をトゥギャりました
交流会もフロントエンドの話題はもちろん、開発環境についての意見交換が行われたり、Golangを勧められるサイボウズ社員がいたりとたいへんに盛り上がりました。

お寿司。 お寿司の写真

トーク中の様子。 トーク中の写真

交流会後の集合写真。モニター越しに写っているのは大阪会場の参加者のみなさんです。 集合写真

次のスシネタは?

次回のCybozu MeetupはSRE (Site Reliability Engineering)をネタとして4月3日に開催予定です。@ymmt2005 より、『SRE なにしてますか? 忙しいですか? 救ってもらっていいですか?』と題してサイボウズのクラウドサービスcybozu.comの運用話を余すところなくお伝えしたいと思います。

  • Cybozu Meetup #2 SRE
  • 日時:4月3日(月) 18:30 会場 19:00 開始
  • 場所:サイボウズ東京オフィス (東京日本橋タワー 27階)
  • イベント詳細:https://cybozu.connpass.com/event/52668/

おかげさまですでに 約100名 以上の参加申し込みをいただいておりますが、抽選制となっておりますので皆様のお申し込みを心待ちにしております。

また、次回からは東京のみでの開催となります。大阪オフィスでは、後日形を変えて開催を予定しております。関西にお住いの方には申し訳ありませんが、しばらくお待ちください。 東京オフィスでは今後も月に1度のペースで開催を予定しています。

東京・大阪とも今後のイベント情報はサイボウズのconnpassグループにて告知していくので、よろしければフォローお願いいたします。今後ともCybozu Meetupをよろしくお願いします!

 

テストエンジニアリングチームができて一年が経った話

こんにちは、東京品質保証部の新関です。

2017年に入り、ちょうどテストエンジニアリングチームを設立して一年が経ちました。設立からのテストエンジニアリングチームの活動が、開発組織へどのような影響をもたらしたのか、紹介したいと思います。

テストエンジニアリングチームとは

まず、テストエンジニアリングチーム(以下TE)の説明から簡単にさせてください。サイボウズのTEは『枠組みを超えて品質/生産性の向上に貢献する』をミッションに設立した、プログラマーとQAのジョイントチームになります。

www.slideshare.net

@miyajanの紹介資料にもありますが、2016年1月に3名でキックオフし、テスト自動化の推進を主に行っています。

TE設立背景は紹介資料にある通り、内部環境の変化により、品質保証への要求も変化し組織自体も最適化していく必要があったというのは勿論なのですが、これまでの自動化アプローチで困っていた諸問題(コスト、自動化が定着しないなど)についても専門でなんとかしていきたい!というメンバーの強い思いも設立要因になっています。

2017年現在、TEのメンバー数は東京6名、ベトナム3名、上海2名の計11名で活動をしています。

以下、時系列順に昨年の活動を振り返っていきます。

1年を通しての活動

2016年 前半

@miyajan含め、3名でキックオフしました。いきなり自動化を進めました、というわけではなく、活動の指針を定めるため、これまでの自動化の整理、共通認識、理想のすり合わせについての議論をひたすら重ねました。

f:id:cybozuinsideout:20170307103646p:plain

チーム方針に対する議論が中心であったため、他部署に対して役立つようなアウトプットを出すことができず、もやもやする気持ちがありましたが、この時期に共通の理想/方針が定めることができたおかげで、

  • 徹底的に議論する文化の醸成ができた
  • 理想が共有できているため、事をスムーズに運ぶことができるようになった

と思っています。併せて、TEの活動プロセスを初期段階で決め、その内容に沿った形で活動を開始しました。

f:id:cybozuinsideout:20170307103813p:plain

2016年 中盤

上海、ベトナムと各拠点において立て続けにテストエンジニアチームを設立し、キックオフしました。日本ではプロダクトチームへ自動化に関するヒアリングを実施し、その中で依頼のあった自動化、CI改善などに取り組みました。ヒアリングをする傍ら、海外拠点で実施する自動化を選別して実施依頼するなど、かなりドタバタした時期でした。
このヒアリング活動や依頼への対応を進めると、各プロダクトで実施されている自動化は独自色が強く、知識も技術スタックもバラバラであることがわかってきました。少ないTEメンバーで、複数のプロダクトの独自システムをサポートをしていくことはなかなか難しく、効率もよくありません。これを統一していくことは多くの時間とコストを必要とすると思われますが、共通化することによるメリットも大きいのではないか、という意見が出てきたのがこの時期でした。
一方で社内イベントでTEの取組みを紹介するTE Cafeを開催するなど、社内に対して新設されたTEを認知していただく活動も開始しました。

2016年 後半

引き続き共通基盤についての議論。海外TEメンバーが来日し技術交流会を開催、STFやモバイルテスト自動化についての調査発表などがありました。

f:id:cybozuinsideout:20170307104500p:plain

技術交流会の後は、あれよあれよという間に一年が。。。\(^o^)/

開発組織にどんな影響があったか

1年の活動を通して下記の影響が出てきました。

プロダクトチームへのヒアリングによる効果

カジュアルなヒアリングを定期的に実施することで、プロダクトが抱えている問題を把握し、自動化に関する相談や依頼を掘り起こすことができました。その結果、以下のような効果がありました。

  • プロダクト独自の自動化の問題点の発見と改善
  • テスト自動化がうまく運用されているチームの手法の横展開
  • 自動化されていない、自動化が廃れてしまっていたチームへの自動化再導入
  • 環境を整えることによる自動テスト工数の削減

自動化を意識した開発計画

開発計画立案時点で、開発チームとTEの間で自動化の推進について議論が交わされるケースが増えていきました。

メンバーの増員

もともと自動化に興味を持っていた開発メンバーにjoinしてもらうことができました。

キャリアパスの一つとしての認識

QA内でキャリアパスの一つとして認識されてきました。

今後に向けて

よりアウトプットを増やしていく

この1年は、方針の策定やヒアリング、人員の増強といったいわば「準備の期間」でした。
今年は、前年よりもより多くの改善活動を、開発者やQAにわかる形で提供できればと思っています。

自動化は勿論、より品質/生産性を高めるためのアプローチの検討

テストエンジニアリングチームは、テスト自動化を推進して円滑にテストが完了することが使命です。
が、それだけにこだわらず、自動化以外にもより品質/生産性を高めるアプローチがないか検討していきます。

We are hiring!

一緒に働いてくれる仲間を募集しています!

 

Excelの奇妙なパスワードとマクロウイルス

サイボウズ・ラボの光成です。

今回はMicrosoft Excelに存在する特別なパスワードの仕様を紹介します。 後半はそれがマクロウイルスと関わるとどうなるか、ちょっとした実験をしたのでその紹介をします。

そもそものきっかけ

それは海外の人からのメールでした。 私はCODE BLUE 2015で「MS Officeファイル暗号化のマスター鍵を利用したバックドアとその対策」を発表した際、 Windows/LinuxでMicrosoft Officeファイルの暗号化・復号をコマンドラインでできるツールmsofficeを公開しました。

そのメールはツールについての質問で、「知人からもらったファイルをこのツールで確認すると暗号化されているのにファイルを開くときにパスワードを聞かれない。なぜ?」というものでした。

最初質問の意味がわからなかったのですが、確認すると確かにファイルを開くときにパスワードが不要なのに中身は暗号化されています。 拙作のツールを使うと暗号に使われている詳細パラメータを取得できます。

bin\msoffice-crypt.exe test.xlsm -info
flags = 00000024
sizeExtra = 0
algId = 0000660e
algIdHash = 00008004
keySize = 128
providerType = 00000018
cspName = Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)
dataSize = 72
saltSize = 16
salt = 0C:A5:...
encryptedVerifier = FF:14:...
...
bad password

暗号化フォーマットとしては不自然なところはありません。とすると「何か特別なパスワードで暗号化しているのだろう」と想像しましたが、どんなパスワードか見当もつきません。 ふとLibreOfficeでも開けるのだろうかと試したら、問題なく開けたのです。

ということはLibreOfficeが何か特別な処理をしていると推測できます。 それでLibreOfficeのソースコードを調べてみたらまさにそういう処理が入っていました(filterdetect.cxx)。

if( aDecryptor.readEncryptionInfo() )
{
    /*  "VelvetSweatshop" is the built-in default encryption
        password used by MS Excel for the "workbook protection"
        feature with password. Try this first before prompting the
        user for a password. */
   std::vector<OUString> aDefaultPasswords;
   aDefaultPasswords.push_back("VelvetSweatshop");

特別なパスワードVelvetSweatshop

ソースコードを読むと、どうやらVelvetSweatshopという特別なパスワードがあるようです。暗号化されたファイルを処理する場合、まずこのパスワードで復号してみて駄目だったら通常のパスワードを求める処理に移っていました。 そこで私のツールでこのパスワードをつけて先程のファイルに対して復号処理をしたらちゃんと復号できたのです。

ちなみにWordやPowerPointでこのパスワードをつけて保存すると、次回開いたときにパスワード入力画面が表示されました。 このパスワードはExcelのみに有効なようです。なんとも奇妙な仕様です。

マクロウイルスとアンチウイルスソフト

さて、ExcelなどのVBScriptを利用したマクロウイルスというものがあります。 1996年頃Larouxと呼ばれるマクロウイルスが初めて登場しました。 それからウイルスの種類が徐々に増えていき1999年ごろ大流行します。その後Office 2007からマクロ機能はデフォルトでオフになり、また会社によってはマクロを禁止しているところもあって近年では下火になっていました。 ただ去年の記事によると2015年ぐらいから再び増加傾向にあるそうです(マクロウイルスを知らない世代の社員が狙われる?「Office文書を開いて感染」攻撃が再び増加(INTERNET Watch))。

アンチウイルスソフトはマクロウイルスファイルを概ねパターンマッチで検出します。 しかしパスワードをつけて暗号化していたらもちろん復号できず、中身をチェックできません。

ただVelvetSweatshopという特別なパスワードをつけた場合、中身は暗号化されていても見かけはユーザにとって普通のファイルと同じです。 パスワードが分かっているので技術的には復号可能ですが、アンチウイルスソフトはこの中身をチェックしているのでしょうか。

そこで実際にLarouxと判定されるExcelマクロファイルを作り、VelvetSweatshopで暗号化して試してみました。 7種類のアンチウイルスソフトでチェックしたところ検出したのは一つだけでした(2017年3月6日時点)。 意外にも素通ししてしまうのが多かったです。

検出したソフトは、「暗号化Excelファイルを見つけたらとりあえずVelvetSweatshopで復号し、成功したら中身をチェックする」という処理をしているのだろうと思います。

実はこの話は海外では割と有名なようで、たとえばWhen is a password not a password?という2013年の記事があります。 今回、メジャーなアンチウイルスソフトが検知しないのを自分で確認して、個人的にはそれはチェックすべきではと思いました。しかしソフトベンダーにとっては、このリスクに対してスキャンするコストの増加が見合わないという判断なのかもしれません。 この件についてMSRC(Microsoft Security Response Center)に問い合わせしてみたのですが、たいして影響がないので(minimal impact)特に対応する予定はないとのことでした。

いずれにせよ最近は個人を狙った標的型ウイルスが多いそうです。ファイルを開くときやマクロを有効にするときにいつでも注意しなければならないのは実践するのが難しく、悩ましい問題ですね。